AMP Pages on Mobile Apps Visitors Tracking

[leo28]

Hi, I am reaching out to ask questions related to the way Adobe measures AMP pages consumed within external apps.

Here is some background:

• I know AMP pages tend to be a stripped-down version of our regular pages and users that interact with them are not saving cookies and thus will always be considered a "new visitor" regardless of how many times have this device visited our pages
• Mobile app visitors are measured a little bit differently as they don't need cookies. Adobe assigns an ID to the app and keeps using the same ID until the app is uninstalled.

However, we've come to an unforeseen case: what if our users are consuming our AMP pages through a third-party app?

Are these visitors being deduped due to consumption happening within an app?

When looking at the data I formulated that hypothesis, but I wanted to discuss what could be happening here. 

Within my data some major apps that seem to be removing duplicated devices are the Android search bar widget and the newsbreak app.

Any intel/insight on what may be happening here will be well-received.

Thanks,

Leo

[Damonwhall]

I'm not 100% sure what the question is here.  Is it that you are wondering whether or not some devices that are using a 3rd party app are deduplicating when naturally visits are not being deduplicated?  

Not sure what is happening on your environment, but it might be that using the concept if an FPID and then using a metric that provides a distinct count of the FPID will get you to and exact user count (also creates resilience against session issues, making seeing your returning visitors more clear). 

• How to implement an FPID: https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/identity/first-party-device-i... 
• Why you should: https://experienceleague.adobe.com/en/docs/platform-learn/data-collection/edge-network/generate-firs... 

Likely i probably missed the point of your question (sorry if I did).

[Jennifer_Dungan]

Hi, 

So depending on your implementation, your AMP pages may not always be treated as new user...  Google AMP Script does have an AMP ID, and that can be passed into your analytics implementation as an identifier (it won't roll up to your website or app ECIDs, but you can at least see some limited info about return visitors). That is what we do, so we can get PVs/V and PVs/UV on our AMP implementation... that might be the case for you, you should check.

Also, it's entirely likely that your AMP pages are being shown inside third part apps, many social media apps, if they see the amphtml tag will load the amp version of the page in their webview instead of your website version. 

Even if the AMP pages are shown through a third party app, the tracking will be the same as how AMP tracks, because this is really just a "frameless browser" experience within someone else's app...  The apps won't be applying any logic to the tracking, they are simply loading a webpage inside a simplified browser.... they have no sway or control over what happens inside that webview.

[leo28]

Thank you @Jennifer_Dungan this helps a lot.

For context I am seeing a lot of these users on third party apps AMP pages, but then when rolling into all the other users the increment is minimal... which could mean we do have deduplication within AMP and most of these users were already visiting my sites on AMP pages elsewhere. I still need to validate our implementation with our dev team.

Also, to pick your brain a little bit more: you said my AMP pages may not always be treated as new users... would this AMP ID you mentioned be stored on cookies like the ECIDs for regular web calls? I want to determine all cases where this ID is cleaned and we get a new user for the same device.

[Jennifer_Dungan]

There are multiple ways to track AMP traffic in Adobe.. if you use the older "amp analytics" method, which doesn't have Adobe cookies, you can still pass AMP's cookie identifier to Adobe through the vid (visitor id) parameter, it will look something like "amp-fx1x286_vibaEvIJRJGbWQ" and will create a way to re-identify the same user. It will not roll up to other web traffic, but in it's own "AMP" world, it should id the same user over and over again.

Or your developers may be using the newer AMP Analytics iFrame method, which passes parameters to an iframe loaded in the AMP and can leverage the Visitor ID service and cookie within the iFrame.

If you are using either of the above, then users hitting multiple articles should be identified as the same user, but that is something you would have to check with who implemented your tracking.

I am not sure where/how you are detecting that your traffic is coming from third party apps... but if you are wondering about de-duplication between AMP through the browser vs AMP through the webview... that really depends on if the frameless browser inside the app is sharing cookies with the device browser... you would have to check that.. but within each app, if you are using one of the solutions above, within say the app for "SocialThings" (made up example) App, the identification at the very least should be treating the user as the same id (assuming that app isn't clearing all cookies within itself - like opening a private mode variant).

The only way you will ever know for sure, based on your site, and the social media apps would be to test it...  First, I would confirm how your AMP is coded (and if you have visitor identification even handled... if not, then there's no point in continuing with the rest)... If you are IDing the users, then I would recommend setting up a proxy test with Charles or Fiddler and dig into the tracking calls on the device and see if the IDs are coming out the same for the same user... note that the apps will use the devices' "default" browser, not necessarily the browser that you prefer to use... 

One more thing, AMP is pretty much a dying tech... It's been pretty clear for the past several years that Google has really lost interest in properly supporting it... we are starting to roll out our AMP Decommission now.... I would suggest before you dump a lot of work and effort into this, you might want to check with your team whether it's even worth the effort, or if it's time to start looking at dropping AMP......