in #4573 @cramforce wrote and the issue was closed.
We do not want to make variable substitution available to amp-iframe, because that opens up usage of it for undesired purposes such as ad serving and analytics.
I'd like to request we revisit this issue. The specific use case is video players in amp-iframes. None of our customers are currently using amp-video
or amp-specific version of players in production due to the need for pre-roll ads and the presence of significant existing legacy video infrastructure.
While we can make the players work in an amp-iframe
with some https juggling we can't correlate ads between the video and the page. We'd like to be able to pass to the iframe standard variable substitutions. Some we can do at page build time (static things like page urls) but the CID, timestamp, page view id etc. can't be done statically.
Yes this would allow ads and analytics in iframes. That's what we need to make video monetize at it's full potential.
/to @cramforce
nudge
I think the right solution here is to allow iframes to pass analytics events to the main page and have tracking happen there.
Could be as simple as (in the iframe)
parent.postMessage({
type: 'amp-analytics-trigger',
trigger: 'video-ad-view',
data: data,
}, $parentOrigin);
In AMP analytics the trigger names would need to be auto prefixed to not conflict with (future) builtin, like user-trigger-video-ad-view
.
I like that. Would data be a JSON object that gets merged into the amp-analytics vars object?
That is not what I thought about, but seems reasonable.
I was thinking of an a custom trigger as opposed to custom analytics
config. Both make sense. Definitely something the page would need to give
as a permission to an iframe, of course.
On Wed, Dec 7, 2016 at 2:34 PM, John Pettitt notifications@github.com
wrote:
I like that. Would data be a JSON object that gets merged into the
amp-analytics vars object?—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/6234#issuecomment-265595372,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT6_WTJzs6mH4k-NitqAnFSzv91x8ks5rFzSQgaJpZM4K1wUZ
.
@jpettitt Would you or someone in your company be interested in implementing this?
@cramforce - let me look at the schedule. We're slammed with customer work right now.
Edit: Would you want to do this only for amp-iframe or allow other trame generating code (ads, video players, embeds) to use it.
@jspettitt @cramforce Are you still considering to implement this? Maintain same client id for content inside an IFRAME is something we also need, and we can contribute if necessary.
Would it be as easy as receiving the post message from AMP-IFRAME (only in white-listed IFRAMEs) , and create an AMP-ANALYTICS component on the fly with the JSON received?
I think there would need to be a stub analytics component to catch the message, if only to include the CID and do var substitution. My take was trigger a regular amp-analytics event with a set of vars merged in from the json payload. That way all the AMP substitutions would work.
Fortunately for the company but unfortunately for this we've picked up even more work so I don't see having time to contribute to this before Feb at the earliest.
@cramforce what do you think which approach work best? I think we can work on this
@oliverfernandez I think the configuration of analytics events should be on the main page. iframes should only send events.
@cramforce are you saying that no data can be passed or that the main analytics event is defined in the parent but the variables used by that event can be passed up from the iframe? We'd like to be able to pass variables out of the frame - eg play length for videos.
@jpettitt The latter. The parent should not send analytics hit requests that it did not expect, but iframes can parametrize those it does.
@jpettitt Any chance you'd like to take a shot at implementing this?
@cramforce even more slammed that last time you asked. :-(
We also have an on-going issue with tracking events from a proprietary video player in an <amp-iframe>
. There seems to be two possible approaches:
1) Allow variable substitution into <amp-iframe>
, including key values like DOCUMENT_REFERER, CANONICAL_URL and CLIENT_ID (since without them it's near impossible to relate the video in the iframe to it's container)
2) Allow the creation of customer analytics events within the private IFRAME via window.postMessage() and get <amp-analytics>
to send the events on behalf of the iframe.
The general gist seems to be that the contents of IFRAMEs are isolated from AMP, which would suggest option (2) is more AMP-friendly, in that events are managed (filtered, substituted, secured) by AMP.
Are either of these solutions part of planned update? If not, who/how is the case made?
I suggest we do this regardless of amp-video-iframe
work. Doing https://github.com/ampproject/amphtml/issues/6234#issuecomment-296156703 for both amp-iframe
and amp-video-iframe
(same underlying code) makes more sense to me than just doing it for amp-video-iframe
as it enables analytics for other types of embeds (e.g. an interactive data visualization iframe that similar to a video player, may want to send analytics values).
My idea of AMP video analytics is a common set of variables (e.g. play, seek, fullscreen, etc..) that can come from any video player (amp-video, amp-youtube, amp-video-iframe) but this set is limited and only for events that are common across all video players, we would still need a way to have custom variables that only make sense for certain players to make it to analytics hence my suggestion.
@lannka Suggested we use amp context from now on to create 3p APIs in JS instead of relying on documented postMessage
structures which I totally agree with.
@rudygalfi looks like both DailyMail and RelayMedia can benefit from this. Let's see where it fits in our priorities. @matAtWork PRs welcomed for this as well if this is something you are interested in contributing.
Apologies for the silence - been inundated with (unrelated) tasks, but I'll try to focus on it next week
@matAtWork any updates here? Thanks.
I am interested in working on this
Great to hear this @FinnBorge Is it the first time you are contributing to the project? cc @mrjoro
@matAtWork let us know if you already have something. Thank you!
Yes, this would be my first contribution. It'll take some time to get up to speed 😄
Thanks @FinnBorge! I've invited you to join ampproject on GitHub; once you do that we can assign the issue to you. @aghassemi would be a good contact for any questions you might have; you can reach out here or on Slack.
Great, looking forward to contributing!
Just wanted to confirm: Plan of record is to build postMessage based analytics triggers, right?
@cramforce, have been working through this slowly; plan was to register the iframe path as a valid destination for url substitutions. At first glance it looks like the open PR completes the task.
The idea we discussed here was to not do that, but rather to allow iframes
to send analytics events to the main page, so they can contribute, but not
consume data.
On Fri, Aug 11, 2017 at 9:43 AM, FinnBorge notifications@github.com wrote:
@cramforce https://github.com/cramforce, have been working through this
slowly; plan was to register the iframe path as a valid destination for url
substitutions. It looks like the open PR completes the task.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/6234#issuecomment-321862115,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT68Y-EA3N6KLLZngVxPD-xp5COXdks5sXISygaJpZM4K1wUZ
.
@cramforce does this mean that, as a matter of policy, AMP will never allow the document referrer to be passed in any way to the amp-iframe component? We need that for our analytics, so if you could confirm that, it would be much appreciated.
What if I blacklist CLIENT_ID
in https://github.com/ampproject/amphtml/pull/10884 ?
I added a whitelist to #10884, copying over the amp-analytics sandbox vars whitelist and adding DOCUMENT_REFERRER
. Said whitelist doesn't have CLIENT_ID
in it.
@claudiorodriguez Correct. amp-analytics
is the mechanism to run analytics from AMP pages. The proposal I described above allows hooking amp-analytics
to events and data triggered from iframes.
As discussed in email with @adewale, when using amp-analytics
with Omniture's latest AMP code, we have encountered a marked discrepancy of under-counting 15% of Unique Visitors. At this point in time, there is no solution from them. For this reason, we are forced to use the iframe approach for analytics. I'm unsure if other publishers are aware of the discrepancy, but it most definitely exists if they're using Omniture and amp-analytics
.
The downside with the iframe is the lack of referring domain, which leaves 97% of our reported AMP articles without a referrer. No way to run a digital business with that blind traffic. As one of the largest publishers in the world, we need to be able to properly attribute the AMP traffic coming to our site.
On Thursday, 10-Aug, @adewale said he spoke with you and you were happy to have us move forward of the variable substitution approach if this approach wasn't seeing progress; however, I can see from #10884 you've said the opposite.
We need some wiggle room here. This is critical for us to measure the impact of AMP on our traffic and business as well as to continue our support for the AMP ecosystem.
I discussed with @adewale that the approach that was consensus above would be implemented. It should be possible, although possibly not straight forward, to send omniture based analytics pings that way.
I'm open to solutions, but we do not accept solutions that allows for arbitrary iframe-based analytics collection. That is an explicit non-goal of AMP as it is in violation of our 1st design goal https://github.com/ampproject/amphtml/blob/master/contributing/DESIGN_PRINCIPLES.md#user-experience--developer-experience--ease-of-implementation
This issue hasn't been updated in awhile. Do you have any updates?
@cramforce perhaps allowing variable substitution only for amp-video-iframe
would avoid the concern about iframe based analytics? The core goal here is not to collect more analytics by means of violating AMP policies, but rather to be able to correlate video streams to the outer page session.
@aghassemi for plans on amp-video-iframe
I'm not super sure we can do this. Generally amp-video-iframe
should allow for integration with AMP's build-in video analytics approach.
This issue hasn't been updated in awhile. Do you have any updates?
I am closing this discussion issue in favour of #8524 which is currently in progress actually.
Thanks. And I noticed I had a draft saying: Yes, we can do the substitution
int he video iframe.
On Thu, Jun 7, 2018 at 5:03 PM Ali Ghassemi notifications@github.com
wrote:
Closed #6234 https://github.com/ampproject/amphtml/issues/6234.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/6234#event-1669812812, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFeT911t4-UoScDE53OQ8bSAd7XcdQmks5t6b8_gaJpZM4K1wUZ
.
The idea we discussed here was to not do that, but rather to allow iframes to send analytics events to the main page, so they can contribute, but not consume data.
…
We use AMP-iFrames to display videos from our self-hosted customized player in our AMP pages. In terms of analytics, we can't connect anonymous users between the AMP pages and the AMP-iFrames: that brings basically to two different anonymous IDs. Any idea how we can solve this issue?
We use a self-hosted customized version of JW. The dedicated frames for JW don't work if the player is not cloud-hosted. And the AMP-video-iFrames also can't be setup to work properly with the player.
@jackthebunny 'amp-video-iframe' is explicitly designed to handle this use-case, it supports custom analytics, what are the issue you are running with video-iframe? Please file separate issues and mention @alanorozco on the reports so we can look into them. Thanks
thanks @aghassemi, will chase a detailed report of the issues (for instance: poster image covers the player buttons) and file them. thanks for the swift reply.
Most helpful comment
Yes, this would be my first contribution. It'll take some time to get up to speed 😄