Initial UTM parameters missing from one event

Hi @Derek_Wilson - thanks for your question!

Could you provide some additional information around how you are sending the server-side event? Does it use the same User ID/Device ID as the front end events? 

More specifically, when you check the events in the event stream, is the [Amplitude] ID the same value between the front end and server side event?

This information will help point us in the right direction. Thanks!

The event is mapped to the same Amplitude ID but the User ID doesn’t appear to be populated for that specific server side event. And the device ID is different as well. So it shows up as one user stream but is losing the UTM parameters for that one specific event. 

Thanks for checking on that @Derek_Wilson ! Follow up question - when you check the top of the user’s profile, do you see Merged IDs like in the screenshot here?: https://help.amplitude.com/hc/en-us/articles/115003135607#h_c323d7e5-4662-4a36-b0a1-5110a341e80c

Additionally, in the User Properties at the top of the user’s profile (not in the events), is there a value for the UTM parameter? If there have been merges and the UTM Parameter value at the top of the profile is blank, I believe two event streams may have been merged.

For example, let’s say the user logs Event A under User ID A, Device ID A, and where utm_parameter = XYZ. You then send in Event B for this user (server-side) where Device ID = B. Event B does not contain a User ID or the utm_parameter value in the event itself. Upon receiving this Event B, there is no way for Amplitude to determine that Event A and Event B should be tied to the same user since there is no matching User ID or Device ID, so the event is logged under a new user profile under a new Amplitude ID. At this point, we have two separate event streams.

Down the road, you might set User ID for Profile B that matches Profile A. When that User ID becomes available, Profile B is merged into Profile A, allowing the events to be viewed under a single event stream. In this case, the events that were originally logged under Profile B and then merged into Profile A will continue to not have the utm_parameter value XYZ since it was not available at the time the event was logged. 

The important part here (that pertains to your question more specifically) is that during this merge of event streams, Amplitude uses the most recent user property values for the events moving forward. This is a potential explanation for why the utm_parameter value did not “transfer” to the 3rd event in your funnel chart. 

I’ll pause here for now to see if the above series of events fits what you’re seeing for your users.

Note that regardless of the reason this happens, you won’t be able to update the historical data with the utm_parameter since it was not available at the time of the event. In that case, for the funnel chart, would it work if you were to break down by the utm parameter at Step 1 or Step 2 instead of at Step 3? 

Hi @Derek_Wilson - That’s definitely preferred. If the User ID is present at the time of the event, then the user properties should have no issue carrying over to the server-side event.

Let us know if that doesn’t work!

Hello @tracy.guo,

I’m also tracking “initial_utm_source”, and it seems that the initial_utm_source is well preserved for a same User ID. But in most case, the user comes on our website as an anonymous and then creates an account.

It seems like when I identify the user as a logged user for the first time, the value set by the anonymous tracking on the user property ‘initial_utm_source’ is replaced by the one of the logged user.

So my ‘initial_utm_source” value is the last utm_source before the account creation instead of the first ever utm_source for that user.

Is there a way to preserve the value of the anonymous user ? And does my message make sense to you ? 

Thanks