Saturday, September 15, 2018

Adobe Audience Manager Billing Overview

Every paid digital analytics tool and platform in the market has a structured revenue model and Adobe Audience Manager is no different. Audience Manager's revenue model is essentially based on the number of records ingested and the cost clients pay is tied to usage. Similar to AAM, Adobe Analytics is another platform whose revenue model is based on usage. Here's a link to some documentation that shows how Adobe Analytics reports its server calls which has now been updated to a visual format embedded within in the Analytics UI. 

Audience Manager currently doesn't display client server call data in the AAM UI and is often a common complaint that clients have so this is my attempt to fill some of that gap through this post. Let's dive into the details!

Types of AAM Server Calls

AAM server calls are divided into four types of activities as outlined below:
  • Onsite Server Calls: As the name suggests, these are Audience manager server calls captured either on mobile apps and websites. Essentially all page views and clicks are captured as server calls so any hit that's considered a server call by Analytics is considered an AAM server call if data is forwarded is enabled. These server calls are captured whether a site/app has a client side Data Integration Library (DIL) or Server Side Forwarding (SSF) AAM implementation.
  • Pixel Calls: This is data collected from ad or email impression/click calls made to Audience Manager. An example of how this is captured is outlined here.
  • Ingested Log File Records: This type of server call is incurred when you ingest ad server log files in AAM that populate the Audience Optimization Reports (AOR). The way clients typically get these enabled is by leveraging Actionable Log Files (ALF).
  • On-boarded Records: These server calls are incurred based on records ingested from CRM or an offline data file (e.g. call center, customer demographic data etc).

How to Avoid Extra AAM Server Calls

Recently, I came across a scenario where my client burnt through ~75% of their AAM server calls allocated for a year in the first 5 months. One of the reasons for that was the lack of understanding and visibility of what their server call usage was by activity. Given that majority of their server calls were exhausted early, they had to turn off data collection in the DMP for some time. Below are some easy steps to avoid exhausting server calls earlier than anticipated:

  • Monitor Server Calls Regularly: "Prevention is better than cure" is one quote that comes to my mind to explain this point. I cannot stress how important it is to proactively monitor your server call usage to avoid a scenario similar to what our client faced. Your AAM consultant should be able to pull server call data for you so it might make sense to ask your consultant to schedule a monthly pull of your server calls to avoid any surprises.
  • Collect Onsite Server Calls Only Via One Method: There are two main methods of AAM onsite data collection which are client side DIL and Server Side Forwarding. It's recommended to forward Analytics data to AAM using either client side DIL OR SSF to avoid being charged twice for onsite activities. My preference is the SSF method as it forwards Analytics data to AAM using one call.
    Last year, a change was added to SSF Adobe Analytics data to AAM using Analytics report suites. This method allows clients to selectively forward data ONLY to those report suites whose data you want to forward to AAM. Previously, data for all report suites used to be forwarded over to AAM. Below are screenshots of how Analytics data is forwarded now and how it used to be forwarded before. 
Latest method of selectively forwarding Analytics data to AAM.

This method used to forward data for all report suites to AAM. It's advisable to turn it off even though the new method takes precedence and it can only be done by your AAM or AA consultant.

  • Collect Media Data Either Via Pixels or Logs: Campaign media data collection is another area which can contribute to server call inflation if not done correctly. Last year, the AAM product team introduced Actionable log files (link above) which is a programmatic way to ingest DCM logs and create audience traits without deploying pixels. This method is widely used across AAM to ingest DCM log data for Non-EU markets. The other method is to manually deploy media pixels to capture impression or click level data.
    It's highly advisable to capture media data using ONLY one of these methods to avoid being charged twice.

Finally, What Do I Want to See Added?

Given that one of my client has called AAM billing a black box, I'd like to see the following items added to the AAM UI and billing reports:

  • Display Server Calls in the AAM UI: Like Adobe Analytics, I'd like to see Audience Manager server calls being displayed in the AAM UI so that clients can regularly monitor AAM server calls themselves and make necessary adjustments.
  • Add Report Suite Breakdown in AAM Billing: I don't believe there's a way to see a drill down by report suite ID so I'd like to see that level of granularity added to AAM onsite server calls even though clients now have the ability to control that.

Hopefully this post provides you a general understanding of how AAM server calls are categorized and how to be better prepared moving forward.

Saturday, August 25, 2018

3rd Party Pixel Implementation in Launch by Adobe

Launch by Adobe is gaining a lot of popularity among clients who are either migrating from Dynamic Tag Management or from a different Tag Management system. I've already helped a few clients migrate to Launch and have experienced how robust this TMS is especially in terms of managing the firing of Adobe specific tags and other 3rd party scripts. A 3rd party script or tag is a snippet of code that is deployed either on marketing landing pages or purchase funnels to attribute marketing campaigns to conversion activities.

Launch has a lot of 3rd party tags (see example below) that are supported as extensions which can be deployed via a user friendly UI and the list is ever growing but there will always be a need to deploy 3rd party tags that won't be available in the catalog. 

As an example, below is a screenshot from the Adobe Advertising Cloud extension UI that makes it very easy to deploy this pixel without writing any custom JavaScript.

This post shows how to deploy a 3rd party tag called PepperJam not yet added to Launch and covers the various steps needed to to get it done successfully. Let's take a look.

  • Evaluate 3rd Party Tag Deployment Documentation: Typically, you will get a tag deployment/requirement documentation from your vendor. Once you get the 3rd party tag documentation from the agency or vendor, make sure to go through it to understand the JavaScript snippet, where the tag needs to fire, what attributes need to be passed and how to test the snippet. These are some of the key questions required that need to be answered before deploying any 3rd party tag.

  • Capture all relevant Meta Data using Data Elements: In this case, the vendor requires us to capture the currency code, order total, order ID and a query string parameter called "clickid" that needs to be persisted for the visitor. In the next two screenshots, we create two data elements. The first data element captures the order total by tying directly to a data layer/JSON attribute on the page called dataLayer.orderTotal. The second data layer captures a query string parameter called "clickid" that needs to be persisted for the visitor and we've used the "Visitor" duration. This post covers persistence in Launch in more detail.

  • Create a Rule: The first step in a Launch rule is to create an event. In this case, our event is page load and we're going to choose "DOM Ready" to fire this event. DOM ready is an event which is executed when the document object model has loaded. The next step is to choose a condition. In our case, we want to fire the pixel on a page called activewear.html. You can validate the condition by putting in the URI in the Regular Expression Tester as shown below. 

  • Implement the PepperJam Pixel: The last step in the pixel implementation process is to add an action within the existing rule. We do that by clicking on "Open Editor" and pasting the JavaScript snippet provided by the vendor. Take note of the two highlighted data elements in the screenshot from the code snippet which have been manually added to the pixel to pass additional meta data.

  • Validate the PepperJam Pixel: The final step is to validate the pixel in a browser. As per the first screenshot below, we can see that additional attributes (meta data) such as amount and Click ID are populating based on the data elements tied to the data layer and query string parameter respectively. The second screenshot shows that the Click ID is still populated even if the clickid query parameter is not populated in the URL as we created a Visitor based data element.

Hope you found this post useful. Is there a 3rd party pixel that you've deployed in Launch that isn't supported via an extension yet?

Sunday, August 12, 2018

LiveRamp and Audience Manager Integration

Digital marketers since the onset, have strived to deliver personalized and targeted content to users. That coupled with knowing where users are in the purchase funnel and showing tailored content across multiple devices and channels is what makes their experience truly omni-channel. There's another term coined for this type marketing and it's called People-based marketing. So, how is it all accomplished? 

The following visual shows the various steps involved in delivering a truly unified experience to users across multiple channels and devices. One of the steps we'll cover as part of this post is to do a deep dive on the process of data on boarding.

Data on boarding (step 2) is the process of taking in customer's offline personally identifiable information (PII) and anonymizing it to make it available for online digital marketing efforts. Companies such as LiveRamp specialize in ingesting PII and device/cookie data from various sources and sharing it with Data Management Platforms for further activation. Typically, clients who are unable to connect their customer's hashed profile ID upon authentication with AAM (natural match) leverage LiveRamp but other customers leverage data onboarding as well. Let's dive into how data is shared between LiveRamp and Adobe Audience Manager:

LiveRamp to Adobe Audience Manager

Clients have often asked me how does LiveRamp send data to AAM and how is LiveRamp able to take PII data and anonymize it. At a high level, customers share their CRM data such as email address with LiveRamp which is translated into cookies and device IDs. For AAM, that cookie is the third party UUID that LiveRamp maintains a match table with and provides a batch file that's uploaded to AAM thereby enabling activation in the DMP.

Let's take a look at the various steps involved in bringing LiveRamp data in AAM.
  • Create 3 Data Sources: The first step to create three data sources for taking in LiveRamp data from cookies, iOS IDFA and Android Google IDs. The iOS and Android data sources are created in a similar way and the Cookie data source is created slightly differently as shown below. Please note that these data sources are only created once and can be replicated for all future file based on boarding.

  • Create 3 On Boarded Traits: The next step is to create on boarded traits in AAM based on the 10 digit numeric integration code (ic) provided by LiveRamp for each uploaded (file) set of cookies & device IDs. The following screenshot shows an example of a trait that's created to tie uploaded Android device Id data from LiveRamp to AAM. Make sure to create three flavors of these traits tied to each data source (iOS, Android and Cookies).

  • LiveRamp to upload data to AAM (S3 or FTP): Once all the relevant data sources (can be reused) and onboarded traits are created, the LiveRamp contact will push UUIDs or device IDs to AAM via a batch file process.
  • Monitor Onboarding Status Report: The last step is to monitor the Onboarding Status report and onboarded traits in AAM to validate if the LiveRamp uploads are setup correctly.

Finally, once data has been successfully onboarded from LiveRamp, you can map these traits into segments and then to various AAM destinations for marketing activation.

Audience Manager to LiveRamp

Almost all scenarios involving LiveRamp deal with data being onboarded to a DMP, but there is a way to send Audience Manager segments back to LiveRamp as well. That is made possible with the Server to Server (S2S) integration that AAM has with LiveRamp where UUIDs and mobile IDs are sent back to LiveRamp. A use case for that is propensity modeling where customers take in "enriched" audiences originally shared from LiveRamp to AAM back into their CRM system for further optimization and enrichment. 

To summarize, we covered what role LiveRamp plays in anonymizing customer's PII data, how that data is shared with activation platforms and how it flows back into the CRM for further enrichment. I would like to hear about how you're leveraging data on boarded to a DMP back into your own CRM system.

Sunday, July 29, 2018

Adobe Analytics and Audience Manager Data Sharing Scenarios

Recently, I wrote a post about Audience Library which was about data/segment sharing within the Experience Cloud. A similar question came up while working with a client and colleague around the type of data that can be shared between Audience Manager to Analytics and vice versa. That gave me an idea to write about it and share my insights on what kinds of use cases can be met by sharing data between these solutions.

I'm going to cover three different scenarios in which data can be shared between Analytics and Audience Manager and the use cases that go along with it and will be using the Hedge Trimmer garden tool as an example. So, let's get started!

Analytics to Audience Manager (Batch)

This is the easiest way to share segments from Analytics to Audience Manager as this integration is available for any customer subscribed to People Core services. We do that by clicking on the checkbox as shown below but there is a cap of 20 segments that can be shared by this method. To share Analytics segments with AAM and the Experience Cloud, click on the checkbox as shown in the screenshot below and it takes about 24-48 hours for it to show up in AAM. The other thing to note is that you don't require a technical integration between Analytics and AAM as this method automatically shares segments but I highly recommend setting up the integration using either of these methods.

Below are some analysis use cases that can be satisfied using this method of sharing.

  • Complicated Segments that Cannot be Easily Created in Audience Manager: A very common scenario I've seen with clients is to share any Analytics segment by default that they can easily create in AAM such as traffic to a particular page. However, it makes more sense to ONLY share segments that cannot be easily created in Audience Manager. An example is Revenue which is not readily available as a metric in AAM but it is available in Analytics. In the example below, we've created a segment that is tied to users who spent $30 or more on Hedge Trimmers and shared it with AAM by clicking the checkbox. 

  • Technical Analytics->AAM integration is Not Set Up: The other use case where you may want to share Analytics segments to AAM is when either the client side or Server side forwarding integration is not setup between these two solutions. A few clients in the early stages of Audience Manager implementation or during a POC may want to leverage this feature to start sharing segments with Demand Side Platforms for marketing purposes.

  • Need to Send Historical Audiences before Technical Integration: The final use case is prevalent when clients want to send audiences from the last 3 months to DSPs for a media campaign but their technical integration is only 7 days old and don't have enough data. That's where we can leverage this segment sharing feature. 

Analytics to Audience Manager (Real-Time)

This is the most common and recommended method to share segments between Adobe Analytics and AAM and it requires either a client side or server side integration of Analytics with AAM. The advantage of this integration is that this data is collected in real-time and rule-based traits created with this data can be mapped to a segment and activated on immediately. Below are some classic use cases that are executed using rule-based traits.
  • Retargeting: Site analytics data captured in AAM can be leveraged for retargeting use cases. The example below is a rule-based trait that is created to retarget potential hedge trimmer customers who viewed the product but did not purchase yet.

  • Personalization: Another very common use case is personalization where site analytics data can be leveraged and segments sent over to Adobe Target to show contextual content to users. An example of this can be showing a page customized for garden tools to visitors who are actively shopping for Hedge trimmers.

  • Conversion: We can measure conversion by creating Conversion traits. This type of rule-based trait is created by selecting "Conversion" from the "Event Type" drop down in the trait UI. As an example, a Conversion trait can be tied to either campaign landing pages or actual orders captured in Adobe Analytics and be analyzed using the Optimal Frequency report in AAM to measure campaign effectiveness.

Audience Manager to Analytics (Audience Analytics)

I'm not going to give a walkthrough of Audience Analytics as it's already covered in detail here but it's a way to send Audience Manager segments to Analytics. Audience Analytics is still relatively new and there'll be more analysis use cases that customers will find from it but in this section, I'm going to cover three use cases that will be helpful to measure via Audience Analytics. One important thing to call out is that AAM data will only start flowing into Analytics once we add a report suite to the Analytics destination in AAM.
  • Tie Offline Conversions/Attributes to Online Activity: With Audience Analytics, we can tie offline attributes to online sales as well as tie offline sales to online activity. In the example, we're looking at demographic information captured from a CRM system and tying it to online sales for garden tools.

  • Customer Journey Analysis: Another important analysis use case for Audience Analytics is cross journey analytics where we can measure how prospective customers traverse across various channels/sources and land on the website. This can inform marketers where their marketing budget needs to be spent or shifted. In this example, we see how visitors present in a 3rd party data set move through various sources and eventually land on the website.

  • Measure View-Through Conversions: We can also use it to easily see how many visitors who saw an impression and not clicked, convert or visit certain pages on your website or app. This type of analysis can also be done in AAM but given that Audience Analytics is built within Workspace, you get more opportunities to do breakdowns and analysis than AAM.

The opportunities to measure audiences flowing in and out of Analytics/Audience Manager are plentiful and will continue to evolve but the first step is to leverage this amazing integration between two powerful solutions. How are you leveraging this integration for your business?

Sunday, July 15, 2018

iOS Mobile App Analytics Debugging

Back in 2008, I wrote about debugging web analytics code. Mobile App Analytics testing, on the other hand has always been a mixed bag for me. I've primarily leveraged Charles Proxy to setup a connection between my device and my computer outlined in the instructions here but I've never been able to set it up without a glitch. Given that I mostly use Apple devices, I'm going to cover how to test iOS Apps in this post.

Charles Proxy iOS App

The new Charles iOS App is a godsend if you're looking to validate Analytics calls on an iPhone or iPad. This App costs only $8.99 for a single device and the best thing about is the simple setup which is what makes it a steal in my opinion given all the time it'll save you in configuration. I highly recommend this app if you want to save yourself the hassle of setting up Charles proxy on your Mac or desktop as this App works both on 4G/LTE and Wifi. Note that this method is recommended when you want to test an App downloaded on your iOS device. Here's a link to the iTunes Store to buy it.

Below are some screenshots and a quick walkthrough of how to set it up on iOS.

  • Download the App and "Trust" the App by going to Settings -> General -> Profiles & Device Management on your iPhone.

  • Now that the app is successfully installed , let's take a look at how to set it up to start recording traffic. The first step is to toggle the Status option to "Active". You will see an icon showing "VPN" appear next the cellular and Wifi icons. Next, click on the Gear icon highlighted in Red to go into the Settings screen.

  • The next step is to click the "SSL Proxying" menu to enable SSL tracking which is a very important step. Install the SSL certificate to capture secure packets.

  • Now that the certificate is installed and proxying enabled, we'll have to enable SSL proxying for individual host names. Click the "Disable SSL Proxying" link and again click on the "Enable SSL Proxying" link to enable SSL tracking for a particular host name. You will have to restart the App for it to take effect.

  • You should end up with a list of all host names that will be displayed when you download the Charles log (covered in the next few bullets). You can also manually add hostnames by clicking on the "+" icon.

  • Once SSL proxying is enabled, let's take a look at how to review the logs by going to the main screen and clicking into the "CURRENT SESSION" menu. 

  • Once on this screen, filter for the host name you want to analyze as shown in the two screenshots.

  • You can now review the analytics request by clicking on the "View body" option under REQUEST BODY.

  • The issue with the Response header is that it's not easily legible so it makes sense to share the analytics requests by clicking on the icon highlighted in Green. To clear all requests, click on the icon highlighted in Red. Note that you can share the Charles session via Slack, email or text. This is now my preferred method of testing App analytics requests.

  • You can finally view the output in the desktop app for Charles proxy to see it more clearly as well as share it with others.

Enable Debugging in XCode

Finally, I highly recommend that you enable setDebugLogging in XCode to validate your test App for your own QA.

Please feel free to share other tools or methods by which you perform your own mobile App validation.

Saturday, June 30, 2018

Adobe Audience Library and Where It Fits In

Digital Analysts and Marketers make informed decisions when they have the data they need without worrying about underlying system limitations. I know how empowered our customers feel when they see reporting solutions connect seamlessly with one another.

Recently, I worked with a client who was trying to share a bunch of segments from Adobe Analytics to Audience Manager and Adobe Ad Cloud. It should've been simple given the robust integrations we already have among various Experience Cloud solutions but in this case, we found a gap. The gap was primarily in terms of the number of segments that can be shared (20 segments from Analytics to Audience Manager) and the lack of a direct integration between Analytics and Ad Cloud. So, what was the solution? 

The solution was Audience Library. Adobe Audience Library is built on the same framework as Audience Manager where Visitor segments are shared seamlessly across the Experience Cloud. Audience Library provides us that ability by automatically sharing segments across Adobe Analytics, Audience Manager, Adobe Target and Adobe Ad Cloud with no known limits in how many segments can be shared (I will update this if I come to know of any). 

How To Get Access To It?

  • The first step is to get provisioned with Shared Audiences.
  • Make sure you've implemented the Experience Cloud ID Service on your Website or App.
  • Once provisioned, get access to the Audience Library product in the Adobe admin console.

  • Click on the "People" link with the Experience Cloud product selector menu and click on Audience Library.

Quick Walkthrough of Audience Library

  • The Audience Library home screen will show all audiences/segments created in Adobe Analytics, Audience Library and Audience Manager as shown below.

  • Click on the "New" button to create a new audience.
  • On the segment creation page, you can create a combination of Experience Cloud audiences (retroactive) and Real-time audiences which will look like this

  • For this demo, I created a Real-time segment called "Test Segment for Audience Library" which pulls data from an Analytics report suite tied to a page name.

  • Finally, we check if our segment shows up in different Adobe solutions. In this case, we'll check if it shows up in Audience Manager and Target which it does.

When To Use Audience Library

  • When you've run out of segments to share from Analytics to Audience Manager. 
  • If you want to share Analytics batch or Real-time audiences or both across the Experience Cloud (primarily Analytics to Adobe Ad Cloud or Target) automatically. Note that Audience Manager automatically send segments to Adobe Target as well.
  • If segmentation requirements are based on simple conditional logic tied to Visitors for personalization, retargeting or other use cases.

Limitations of Audience Library

  • Audience Library doesn't allow sequential segmentation like it's possible in Adobe Analytics.
  • It doesn't let you define segment containers based on Page View and Visit like we can do in Analytics.

To summarize, Audience Library is not the ultimate solution for all segmentation requirements but it can certainly solve a lot of problems either stemming from lack of system integrations or limitations in terms of the number of segments needed to be shared. I'd encourage you to give it a try.

Saturday, June 9, 2018

Accelerated Mobile Pages Adobe Analytics Tagging

A few months ago, I participated in a "Hackathon" at work and was tasked with creating a technical guide outlining how to set up Launch by Adobe on Accelerated Mobile Pages (AMP). In this post, I'll share a link to the tech guide I worked on as part of the Hackathon as well as cover basic Adobe Analytics link tracking on AMP pages. 

According to the official AMP website, AMP is an open-source library that provides a straightforward way to create web pages that are compelling, smooth, and load near instantaneously for users. AMP pages are just web pages that you can link to and are controlled by you. One of the reasons why these pages are "compelling, smooth, and load near instantaneously" is because they don't run any JavaScript. 

Digital Analytics tags as you already know, rely almost entirely on JavaScript and not having it enabled introduces a lot of implementation challenges. This post covers two different methodologies by which we set up Adobe Analytics page load and link tracking using AMP. I'll also share links to some sample pages with you for you to set them up on your end. Let's dive right in!

AMP Pages Tagging via Launch by Adobe

Before we get started, it's important to call out that this method supports the Visitor ID Service, Adobe Analytics page view tracking and Adobe Audience Manager. Adobe Target and link tracking are not supported with this approach. 

Here's a link to the public facing technical guide I created that walks through how to do Adobe Analytics page load tracking on AMP pages. I'm going to reference certain components from it in this section.

Validate AMP Syntax

The first step is to make sure your site is compatible with AMP. To do so, paste your code into the AMP validator code editor. Below is a screenshot from the validator site showing that my test page passed (click on the image to enlarge) the syntactical check on the validator site.

Add References to Libraries

We need to reference a couple of JavaScript libraries which are compatible with the AMP platform. These are pasted below and highlighted in the screenshot. Make sure to reference these correctly as shown in the screenshot.

  • (Mandatory file for any kind of analytics tracking in AMP be it Adobe Analytics or Google Analytics.)
  • (Required if you want to setup Adobe Analytics using any Tag Management solution such as Launch by Adobe)

Leverage  the "adobeanalytics_nativeConfig" Template

This is the most important step in the overall configuration. This method makes use of the "adobeanalytics_nativeConfig" template to host the Launch by Adobe library in an iframe as well as outputs meta data required to pass data over to the Analytics tag.

There are two main components of the code as shown in the sections highlighted below.

This is where the iframe (Red) is added and meta data (Blue) to pass along

The "iframeMessage" section (Red) contains the link to the iframe URL along with additional data points such as page URL, referring URL etc along with the iframe domain which in this case is my blog. The next two screenshots see how "iframeMessage" is linked to a separate "iframe" page on my blog.

The "extraUrlParams" section (Blue) contains any meta data you want to pass along to the Tag Management tool and eventually to your Analytics solution. We can think of this as a virtual data layer. is where the Launch library is hosted

The HTML of the iframe page is very simple where all we've included is the Launch by Adobe library code.

HTML of the iframe page reference added here

Setup Adobe Analytics Extension in Launch

Install the Adobe Analytics extension in Launch.

Create a data element to override the page URL to capture the parent page URL instead of the iframe URL.

Validate Adobe Analytics on the AMP Page

Here's a link to a page I created to showcase the capability of this hosted on a server. Also, here's a link to a couple of simple AMP pages which when hosted on a server, will fire the Adobe Analytics tag as shown below. 

Caveats with this Approach
  • This method doesn't work on Adobe Target due to the iframe
  • Link tracking doesn't work with the "adobeanalytics_nativeConfig" template
  • We've seen issues with Safari where the iFrame is unable to set a cookie and the Visitor object thereby affecting the Visitor/Visit count

Link Tracking on AMP Pages

This section is based off the instructions provided in the official Adobe documentation. I've added a simple addition to show how to fire off events as a client asked about it which are not listed on this page. Let's go through the setup.

Link Tracking Code Setup

The screenshot below shows the code that we need to use to setup basic image pixel based page load and link tracking on AMP pages. At a high level, there are three main sections in the code.

  • The "requests" section (Red) contains a definition of various Adobe Analytics variables that are referenced for the page view and link tracking image requests.
  • The "vars" section (Blue) contains variables that are mandatory to send the image request such as tracking server and report suite.
  • The "click" section (Orange) is where we define all variables needed to be sent as part of the link tracking call.

Validate Link Tracking

Below is a screenshot that shows the Adobe Analytics link tracking call.

Caveats with this Approach

Here's a link to a page hosted on a server that has a click tracking example for AMP. There are lot of issues with this method which are taken from the test page hosted on Adobe's Github

  • Visitor/visit counts will be hyper inflated.
  • Visitor ID Service is not supported.
  • No way to tie a visitor back to the originating site (no measuring new vs repeat visitors or user acquisition).

Given that the link tracking method on AMP causes visitor duplication, my recommendation is to go with the first method which leverages an iframe. How are you tracking your AMP pages?