Hi @Felipe ,

Thanks for writing into Community. Happy to help! Correct, the initial_utm should not change. Unfortunately, this would be seen as a non-critical issue as no data blocking is happening and this is often seen and usually down to an implementation error on the client’s side. 

If you could attach the screenshot, and a user URL link I can take a look at the change that is occurring. I assume you are using the latest (or a relatively new) JS SDK and you have enabled web attribution as outlined here. If tracking is enabled, then the SDK will set the values as user properties (e.g. referrer or utm_source) once per session (this is last touch attribution). The SDK will also save the initial values using a setOnce operation (e.g. initial_referrer or initial_utm_source), and once set that value will never change (this is first touch attribution).

Note: By default, the SDK will only save the values at the start of the session. For example, if a user lands on your site with an initial set of UTM parameters and triggers some flow that causes them to land on your site again with a different set of UTM parameters within the same Amplitude session, then that second set will not be saved. You can set the configuration option saveParamsReferrerOncePerSession to false to remove that restriction so that the SDK will always capture any new values from the user.

Note: By default, the SDK will carry over existing UTM Parameters and Referrer values at the start of a new session. For example, if a users session expires, the SDK will map the user's Referrer and UTM Parameters to existing values. To reset those values to null upon instantiating a new session, set unsetParamsReferrerOnNewSession to true.

I hope this helps for now!

Kind Regards,
Denis

Hi Denis!
Thanks for the quick reply :)

Sorry if missing something here, but if initial_utm_ values are solely handle by Amplitude’s SDK and the only option users have regarding this is to enable tracking or not, how can this be an implementation error on the client’s side?

Here is a screenshot of the utm values captured in the first event ever registered by the user:

And here you can see how the initial_utm_ is changing in the next user session:

And here you can see what amplitude is showing as initial_utm_ values as the user’s properties (has changed again in the last session): 

Not sure if yo can see this, but here is the user lookup url:

https://analytics.amplitude.com/joppy/project/203418/search/amplitude_id%3D358405555204

As you can see: utm are tracked correctly. The only issue is the initial values have changing on every new session, when, as you’ve said, once set that value should never change.

Our page when the SDK is implemented (through tag manager) url is: https://app.joppy.me/ 

Let me know if there is more info that can help you to better understand what is going on.
Thanks!

Hi @Felipe ,

Thanks for the response and the details. Looking into trying to debug this from my side, I have a few notes to point out ;

1. You are using quite an old version of the JS SDK, which I would not recommend. Is there a reason for this? With older versions, certain methods might be obsolete/not exist and there can also be limited functionality. Would you be so kind as to consider switching to a more up-to--date version here? -> https://www.npmjs.com/package/amplitude-js
2. Keeping the older SDK in mind, I believe you also have older SDK logic. So, the initial_ value changed for that user because they are on multiple devices. You will see that the user's first event ever has ;
   initial_utm_campaign: nextail
   initial_utm_medium: offer-share-company
   initial_utm_source: joppy
   Device_ID: 703ee1cf-cb35-4787-8e3c-02289a604821R
   User_ID: None, Anonymous user. 
   
   These(initial_utms,Device ID) does not change until and including Feb 5th on this event. 
   
   
   Then, on March 22, 2022 at 6:49:01.403 pm CET, we have this event.  We can see the initial_utm parameters do change and you are absolutely right, that should not be the case., but there are things to account for. This was older SDK logic and no longer applied. As you can see on that event, it also has an Event ID of 1, which should not happen as we previously had an Event ID 1. We we also see the Device ID changes to 

   c21fe6b5-c21f-4e64-afcf-e34486eff0acR and with no User ID, Amplitude assumes it was a new user and therefore, they do get their initial_utm parameters. 
   
   We then have the next change on this event on March 28, 2022 at 5:11:09.563 pm CEST. We get new initial_utm parameters again. However, this is a different Device ID 

   945a703b-6405-4e75-a13b-7c8f69a20a4bR and once again, no User ID, so Amplitude assumes it is a new user and assigns their initial_utm parameters. Even when it is merged later here, Older SDK logic indicates that the most recent property values for the intial_utm get applied. Please updates your SDK so this no longer happens. The same thing happens on this event where the Device ID changes to  f8e3ddf2-cbcc-4ad6-a032-cc95dad07eeaR and no User ID. And on the merge on this event, the most recent initial_utm parameters are kept. 

3. This matches with the Merged Amplitude IDs and Device IDs we see at the top of the profile such as 

   384957783051 (merged Apr 4, 2022)

   382082520406 (merged Mar 28, 2022)

   379666026696 (merged Mar 22, 2022)
    

4. I highly recommend the SDK upgrade but also the chrome extension for the Amplitude Event Explorer. It will do wonders for your debugging but also seeing the events the website sends and live user property updates etc. 

I hope this helps! 

Kind Regards,
Denis

Hi Denis!

Thanks a lot for your (really) detailed response

All your flow description is correct. As we load the SDK while our webapp is still loading, the first event gets triggered before the app can set the users ID (it gets set later, when the app is loaded and running). But I always assumed that Amplitude would take care of that stuff when merging the user sessions. In the end is just to always show the first utm_ values for any given user. Do you think the team can fix that?

I’ve updated the SDK after replying earlier. Do you think that even we keep the same flow this issue should be fixed? Or how would you recommend to handle that scenario (we don’t want to delay the events until the web app is fully loaded)?

Cheers!

Hi @Felipe,

If you update the SDK, it will be able to hold the actual intiial_utm on merging of users, the current reason it is happening is because it is older SDK logic. If you update the SDK, it should merge users for their true initial_utm going forward! If you want to update this user’s utm sources, you will need to send in new ones!

It won’t work retroactively but for users going forward, it should work as expected! :) 

Hi again, Denis!
Seems like it is still happening :(

Here is a screenshot of the first event of a user after updating the SDK (you can see the version):

And here is the initial_utm_ values in the user’s properties:

The url of the user look-up is:

https://analytics.amplitude.com/joppy/project/203418/search/amplitude_id%3D388838619603

It’s like the behaviour is still the same (utm are overwrite on every new session).

Having into account the flow I told you before, how can I avoid this for happening?

Cheers!

Hi @Felipe ,

Thanks for getting back to me and updating the SDK, appreciate it! 

So I can see the initial events do indeed change here on April 14, 2022 9:15:37.926 am CEST. However, this event also has an Event ID of 1 again. This makes me believe that there could still be implementation issues with the SDK and how you are setting the Session ID, can you speak with your Engineers once more and ensure they are implementing correctly? 

Regardless, it is indeed a new session and should not have changed, However, the Event ID of 1 does concern me. 

I see these change on the next event too here but this is a HTTP API call so anything that is sent here, must be included in the payload. However, you should also include a session ID so that it can be included into the right session. I can see it changes again here but this,too, has an Event ID of 1. This makes me think the instrumentation is not fully setup yet. Can you speak with your Engineers to fix the Event ID issue and test it again to see if that works? Thank you @Felipe !

Regards,
Denis

Hi Denis! 
I’m the engineer that had implemented this :)

I never set an Event ID or  Session ID in any way. That always handled by the SDK.

As I told you, everything is implemented through Google Tag Manager and in a very basic way.

We load the SDK with the exact code provided by Amplitude on page load. I have only added a callback function to let Tag Manager know that the SDK is load:

amplitude.getInstance().init({{Amplitude Api key}}, null, {
    includeUtm: true,
    includeReferrer: true
}, function(){google_tag_managern{{Container ID}}].onHtmlSuccess({{HTML ID}});});

And then we just use these 3 methods:

amplitude.getInstance().logEvent();
amplitude.getInstance().setUserId();
amplitude.getInstance().setUserProperties();

The only thing that could be weird is what I’ve told you before: we usually call logEvent() at least once before calling setUserId(), as we need to track the landing page the users is seeing before waiting our API finish login in the user and returning the ID. 

Do you think that that could be the problem?

About the HTTP API call: that is an event fired from a service worker on the user’s browser. They are triggered when the user receive a push notification, but they are not active on our app so there is no an active session, so we don’t have a session ID to send with the call.

Thanks once again for your very patient help!

@Felipe ,

That should not be an issue as Amplitude should be able to tell it is the same user once they log a non-anonymous event. I am not a coder myself so it can be difficult to debug these things from our side. 

Ah that makes sense, it can be out of session then. So seeing as it seems to be changing between sessions. 

• includeUtm: If set to true, finds the standard UTM parameters from either the URL or the browser cookie and sets them as user properties. This will set utm_source, utm_medium, utm_campaign, utm_term, and utm_content as well as initial_utm_source, initial_utm_medium, initial_utm_campaign, initial_utm_term, and initial_utm_content as user properties for the user.
  UTM parameters are captured once per session by default and occurs when the user loads your site and the Amplitude SDK for the first time. You can disable the once per session restriction through the saveParamsReferrerOncePerSession configuration option. When the SDK detects that it should start a new session, it will pull the UTM parameters that are available at the time. Those UTM parameters will be set as user properties which will persist for all of the user's events going forward. However, initial UTM parameters are captured only once for each user via a setOnce operation. See the Javascript SDK Configuration Options for reference.

I know you said you did not change the session IDs and the SDK should handle them if it is set up for it, which it should be. The reoccurrence of the same Event IDs is still the biggest concern. Is the service worker that fires the API call able to use the current session ID per chance? This would help with the setting the session ID consistently.

Regards,
Denis

I’ve looked the Event ID definition on amplitude docs:

Event ID    A counter distinguishing events. Event IDs are associated with the device ID.

And looking closer to the users’ look-up activity the Event ID does go back to 1 every time there is session in a new Device.

As everything seems to be merging ok every time a user uses a new Device, I wouldn’t be surprised if the initial_utm values are merging too by mistake, don’t you think? Could you check it with some one from the amplitude tech team?

About your question on the service worker HTTP API call:

I don’t think we can access the session ID from the service worker (pretty sure SW can’t access localstorage nor cookies info).

Either way: the initial_utm values are being changed even without an event triggered from a Service Workers, so I don’t think the issue is coming from there.

Hi @Felipe ,

Thanks for the response! Would you be so kind as to send me your Org ID, Project ID and Amplitude email address you are working with? I think it would be better to make a support ticket to ensure there are no SDK issues on our end. Please PM Me the above information to proceed, thank you!