to re-iterate conclusions from an email thread with @philbooth, we currently only pass entrypoint and utm params with content server events.
this leads to a race-ish condition between auth server events and content server events within the same flow, such that if auth server events (which lack entrypoint) are logged in amplitude first, then they will "take on" the entrypoint value from previous flows, whereas the content server events will reflect the correct values from the current flow.
Example: a user goes through the registration flow and sets the user property entrypoint = foo. Then they go through a login flow with entrypoint = bar, but the auth server events reach amplitude before the content server events. Since the auth server events (e.g. flow_complete) don't set entrypoint, they will be set to foo but the content server events to will be set to bar. this causes a couple of metrics issues.
Can we work on re-piping the entrypoint and utm params back to the auth server?
to re-iterate conclusions from an email thread with @philbooth, we currently only pass entrypoint and utm params with content server events.
this leads to a race-ish condition between auth server events and content server events within the same flow, such that if auth server events (which lack entrypoint) are logged in amplitude first, then they will "take on" the entrypoint value from previous flows, whereas the content server events will reflect the correct values from the current flow.
Example: a user goes through the registration flow and sets the user property entrypoint =
foo. Then they go through a login flow with entrypoint =bar, but the auth server events reach amplitude before the content server events. Since the auth server events (e.g.flow_complete) don't set entrypoint, they will be set tofoobut the content server events to will be set tobar. this causes a couple of metrics issues.Can we work on re-piping the entrypoint and utm params back to the auth server?
CC @davismtl