Tracking anonymous -> signed up users

[jordanh]

Issue - Enhancement

When users who have never logged into Parabol before run the demo, they will receive an anonymous user id from segment (such as 160303e6d841f5-0792ef78a33f0d-727a346f-4a640-160303e6d882f3). After they sign up, they'll receive an official userId such as auth0-deadb33f.... Segment provides an API called alias() that can tie these two ids together in the event stream. Event consumers, such as Mixpanel, support this call. Mixpanel specifically requires:

As soon as you have a userId for a visitor that was previously anonymous you’ll need to alias their old anonymous id to the new userId. In Mixpanel only one anonymous user history can be merged to one identified user. For that reason you should only call alias once, right after a user registered, but before the first identify.

You’ll also want to track the action that caused the user to be identified or created. Read our guide on how to identify new users to learn why.

If we want to track the end-to-end adoption flow, we'll need to make some changes. Segment recommends doing this all client side:

If an identify or track call arrives to Mixpanel with a new distinct_id too quickly after an alias call, there is a race condition between the event and the alias call. As long as your identify and track calls arrive ~1 second after the alias, this shouldn’t be an issue; when the alias queue is backed up, Mixpanel queues events as well, mitigating the race condition.

However, in cases when events are processed too quickly, before their corresponding alias, your calls can result in split/duplicate profiles.

Mixpanel’s client-side javasript library fixes this issue by continuing to send track calls to the original mixpanel distinct_id while the records update. To leverage that protection and avoid creating split profiles and broken funnels, we recommend doing all aliasing for Mixpanel on the client side through Analytics.js

Janky. 😒

I suggest we still do this server side, but we be careful. It seems if we flush the event queue on the server before allowing subsequent events, we're safe.

analytics.alias({ previousId: anonId, userId: '12345' });
analytics.flush(); // flush the alias

analytics.identify({userId: '12345'});
analytics.track({
  userId: '12345',
  event: 'Connected Facebook'
});

Acceptance Criteria (optional)

When an anonymous user signs-up:

• We pass the anonymous id from the client to the server in the login mutation
• In the login mutation, if we have a new users and we have a previously anonymous user we block on the Segment flush() call until alias event has propagated

• Estimated effort: 12 points (see CONTRIBUTING.md)

[mattkrick]

this was blocked by #2017 since the login/signup views were gonna be replaced.