Tracking Visits from users who clicked on email links

[SeánKe]

Hi there, 

We have a scenario where our email system and our AA instance are wildly off. I know comparing between two platforms always leads to issues however there is no trend whatsoever between the two systems. 

We decided to run a test, an email campaign that would only be sent to select internal users, and test on a multitude of devices, browsers etc. The email would contain a number of links to products and has unique campaign info that we can use to know that it is only our data. We found that all users using desktop were tracked as expected, so no issues there. However on mobile, only 3 of the 8 tests we did reached AA. In instances where we clicked on the email link from a mobile browser, seemed to reach AA ok. However, if we clicked on the links from outlook or gmail apps, there were more issues with receiving the data in AA. 

My question is - does anyone know of any issues surrounding email app clicks and how that works with AA tracking? The link clicks have opened both in chrome and safari. This is NOT a cookie consent issue, we are always accepting cookies during our tests and we are sure of this. 

Any insight would be a massive help. 

Thanks

[bjoern__koth]

Hi @SeánKe 

Can you confirm that there are no redirects in place that could potentially cut off request params? Just a wild guess.

Outlook does such things, but then I would expect that behavior to work the same way on web and mobile.

Which params do you use?

[SeánKe]

No redirects that I can notice. The relevant query param is in the url on my phone when the page is loaded

[bjoern__koth]

Worthwhile checking your network traffic through a proxy like Charles Proxy (https://apps.apple.com/ch/app/charles-proxy/id1134218562)

Maybe this gives you an idea of aborted tracking requests that could explain what's happening.

The general mobile traffic is captured as expected?

[Jennifer_Dungan]

Hmm that is interesting... what type of device (iPhone or Android)? The WebView shouldn't have issues inherently... but maybe there is something in the way your site is rendering?

I haven't noticed this myself, but I will try to do some testing and see if I can replicate on my own site...

[Jennifer_Dungan]

I tested on the gmail app on both my Android and iOS testing devices... in both cases the parameters were tracked perfectly along with the rest of the page content from within the webview (I used a proxy tool to verify the actual hits)

I don't currently have the outlook app installed on either device... 

Would you be willing to share a link with me, that I can test myself (it can be sent to me via a private message so that it's not available here publicly), so that maybe I can see what might be happening?

[SeánKe]

Hi Jennifer, 

I've continually tested this issue and I had noticed several instances of users who clicked on email links and opened in a private safari browser, their visits were not captured in AA. Having said that, we have also done tests on private safari browser that does reach AA, so its hard to draw any conclusions from this. 

We are using the AA extension and using a tracking server / SSL tracking server domains of smetrics.clientname.co.uk. 

Do we know if there is a consistent means where a private safari browser can block tracking being sent to AA even when a user opts in to analytics cookies? In my privacy report in safari I can see under "Trackers prevented from profiling you" adobedtm.com and demdex.net (this last one makes sense as a 3rd party).

[Jennifer_Dungan]

Are you using the Adobe hosted Launch files? Those use the adobedtm.com domain... we switched to self hosting years ago to reduce the potential impacts of blockers. Of course, it doesn't help the blockers that look for the "/b/ss/" pattern in the tracker... but by making our files hosted locally to our domain, they are less likely to be blocked at the domain level.

[SeánKe]

When you say adobe hosted launch files - is this where the launch library is managed by adobe within the AA extension settings? 

[Jennifer_Dungan]

The default "host" is managed by Adobe:

However, you can create your own SFTP host (https://experienceleague.adobe.com/en/docs/experience-platform/tags/publish/self-hosting-libraries

In our setup, the files go into an SFTP bucket, then we have a job to copy the files from SFTP into our webserver. Because of these steps, I leave our Dev/QA builds on Adobe Hosted, then Staging and Prod use our own solution.

This means that development work is quick and flexible, then release candidates and production go through a proper deployment process.

[SeánKe]

Ah yes apologies - yes we are using the adobe hosted launch files. So that explains the adobedtm.com value in the privacy report. 

What I can't understand is a lack of consistency of when visits do/don't make it to AA. 

[Jennifer_Dungan]

You're right, the inconsistency is strange.. I would expect the private mode to work... or not...  (not sometimes).

Moving to self hosting is a potential option to improve things, but it's not something you can just do overnight...

[SeánKe]

Hi Jennifer, 

One thing we've just spotted in our testing was that it might be a site/brand specific thing. We have one launch container for two websites. In our testing we have seen private safari has not fired on one of the brands, but not the other. 

Weirdly, in our AA extension we have our SSL as tracking server / SSL tracking server domains of smetrics.clientname.co.uk. The two sites have different domains, but weirdly the domain that isnt in that tracking server value is the one that tracks as expected. Is there anything I should be looking for that would block AA on one domain but not the other when its the same launch container for both? 

Thanks!

[Jennifer_Dungan]

Hmmm.. interesting... so you are saying you have:

domainA.co.uk

and

domainB.co.uk

Both are setup with the same tracking server smetrics.domainA.co.uk

And you are indicating that there are issues with domainA not working, but domainB is? Or are you saying there is an issue on domainB? 

If the issue is in fact domainA, that seems very strange, I would sort of expect if any scenario was going to have issues, it would be the cross domain scenario (domainB using domainA tracking server).

I too use a single launch property for multiple sites, but I set up a tracking server for each domain (smetrics.domainA.co.uk for domainA and smetrics.domainB.co.uk for domainB - even though the sites are going to the same suite). I like to make sure that as much as possible I keep our implementation as "first party as possible"

Now, if I misinterpreted above, and you are saying that you're having issues with the cross domain solution, I would recommend getting a new tracking server created, and I can show you what I did to load the domain specific tracking server.

[Pablo_Childe]

Hi what you are experiencing is normal for native apps. They are basically blocking the adobe beacon as its seen as a 1 x 1 pixel and natively they (user setting ) treats it like potential spam or is stripped out as the click event in native app doesn't fire a Adobe beacon. You will likely never be able to force all users to change app settings so can expect such deltas.

Can you verify though when users are clicking from within the native app are you getting the resulting web URL with the expected tracking IDs on the website from that click through(if yes do you see your campaign variables in web beacon for that page load)? Also what email tool are you using to send these emails out with? Adobe Campaign? or something else?

[SeánKe]

Hi Pablo, 

Apologies I hadn't seen your response! 

We use cheetah/engage+ so separate from the adobe stack. 

Our difference since Jan 2023 averages out at 80% between the two platforms - I wouldn't expect that to be so high? Our campaign details persist from the email clicks to landing on the website. 

Thanks