Add ability load analytics iframe and post to that iframe

[cory-work]

Many media companies have complex analytics needs which may be difficult to fulfill with a model where the majority of analytics data is statically available on a page. My proposal is that amp-analytics provides support for loading an iframe that better suites some of these complex requirements.

Something along these lines:

<amp-analytics>
<script type="application/json">
{
    "targetIframe":"analytics_frame",
    "src":"https://amp.example.com/analytics_frame.html",
    "vars": {
        "type":"iframePost",
        "pagename": "TITLE",
        "vid": "123"
    },
    "triggers": [{
        "track pageview": {
           "on": "visible",
           "vars": {
              "eVar1":"evar1 value",
               "pagename":"pageview TITLE"
           }
        }
   }]
}
</script>
</amp-analytics>

• target_iframe - defines the id of an iframe to be created
• src - the page to be loaded into the iframe

When a pageview is triggered all the defined vars associated with that pageview will be sent to the iframe via a postMessage call.

[cramforce]

Could you give a concrete example as to what the iframe would actually do? This request has come up and denied before as it would lead to the same situation that AMP has been trying to avoid where N analytics providers have N times the overhead.

I can't really see what this iframe would do that couldn't be done on the server side. I realize that sometimes it is easier to do on the client side, but the AMP project is all about solving problems on the right layer for acceptable performance.

[cory-work]

The idea here is that an implementer could have the same tracking code for both their AMP pages and the related canonical non-AMP page. This would make it easier to do their tracking consistently.

Furthermore, publishers are already doing complex javascript work to set up their tracking requirements. Were I a publisher I would consider it a barrier to entry to re-implement that work server side. By posting to an iframe the publisher more easily adopt the AMP vision (which, by the way, I support).

As to the "N time the overhead", I don't understand the concern here. Could you elaborate what you mean by overhead?

[cramforce]

With "N time the overhead" I meant that most complex sites have many analytics integration would end up having many of these iframes.

I still don't understand what this iframe would do. Since it would rely on post messages from the page, it would require significant changes to the JS code, which one might as well do on the server side.

I think we should rather discuss, what changes, if any, we should make to amp-analytics to make the server integrations easier.

[cory-work]

Ah I see. Yes complex sites would more than one iframe but probably not more than 5 for analytics. Those sites would likely have 2-3 more for other content like video bringing the total to around 8.

As an aside a technique like this might actually reduce the number of analytics calls made from a page as the publisher could send all analytics requests to an iframe and let it, asynchronously, handle those calls (a server side call could do that as well).

As for the changes to JS code I daresay that most publishers are already handling analytics requests client side and, as such, would rather continue to do so rather than stand up a new server side handler for AMP pages. Furthermore some customers may require calls to 3rd party apis to retrieve analytics data. If those calls require cookie data this could not be achieved on the server.

I'm happy to discuss any method that will make this simpler for integrations. I am still of the opinion that allowing the loading of an analytics iframe is the lowest barrier to entry.

[cramforce]

You could achieve the cookie based work by using the URL based analytics config and potentially redirecting through multiple hosts.

The reduction in calls can be done without the iframe as well, although the number of async calls is not really that much of a concern in general.

We do care about ease of adoption, but not at the expense of our performance goals.

[cory-work]

I am 100% behind the performance goals and I don't think this solution would adversely affect those goals. The iframes would be loaded asynchronously so the visible content shouldn't be impacted.

The example I gave you for the 3rd party cookies is one in a number of such examples. There is another situation where we write a 1st party cookie or depending on the value of a 1st party cookie do something differently in a call to a 3rd party. I'm not saying this couldn't be done server side but rather it becomes quite burdensome for publishers to have to deal with this sort of interplay.

Also publishers that we deal with have several custom libraries that cause different behavior. To re-implement all of this function will be a rather high barrier to entry.

I need to do some retro-fitting to get my changes to work with the current release. I'll send you my pull request so we can chat about my proposal with a full context.

[rudygalfi]

We determined awhile back not to support this method of analytics collection. Closing this out.