Closed alexmaurizio closed 6 years ago
to @lannka
This seems to be a bug. Can we not force it here? If remote frame is disallowed for an ad network, it should just be ignored. @keithwrightbos
Hello @lannka @aghassemi , sorry to bother you, but what's the state with this issue?
We are currently rolling out AMP for all the blogs in our hosting service, and while we have no other problems that we know of, we cannot enable it for high level bloggers yet because they will require Teads Inread and Outbrain Ad positions with our specific adserver tracking - without this fix we cannot allow AMP on those users, since they'll be missing vital ad positions.
I could ask for some spare time in office and work with you on an I2I for this specific problem, but I cannot guarantee this!
Thanks, Alessandro
@alexmaurizio sorry for the wait. I think it should be fixed. let me follow up with @keithwrightbos offline before we can go for it.
Agree that in the event there are a mixture of amp-ad types on the page, remote HTML valid for others shouldn't cause AdSense to break. However, note that remote HTML is only for delayed fetch implementations which for AdSense is only canonical (and we're working on removing that as well). As such, it is highly encouraged that should the slot ultimately request Google Ad Manager, the amp-ad type doubleclick/adsense is used an in a way that does not require custom JS execution. Can you elaborate on why you need the custom JS script? Is it necessary for amp-ad type=adsense or doubleclick slots?
Thanks @keithwrightbos . I will go ahead and remove the assert
to fix the issue.
Meantime, I think @keithwrightbos has a good point that @alexmaurizio you might revisit that if you indeed need remote html to run custom script. What "specific tracking" you were talking about? Could it be done with amp-analytics?
@alexmaurizio this fix is merged. it will enter canary build next Tuesday and you can start some testing. If everything good, it will be released to prod the week after.
@lannka @keithwrightbos thanks a lot for the fix! We'll surely test this asap.
I'll explain more on why we need a custom tracking javascript not implementable via amp-analytics for the positions.
First of all, this is not for adsense, dfp or anything Ad manager related. The current implementation is correctly working for Adsense responsive banners in page and Outbrain. And it's doing great :)
For our high-quality bloggers, we also have a Teads Inread (outstream video) format injected for the users instead of one of the adsense banners. We basically offer our service in a revenue sharing service (using ad-host for adsense managed by us, for example, for which we still don't have native adunits generation available via Host API.. but that's another issue :D).
Teads uses specific tags for each one of our vertical blogging platforms (7 different platforms). The problem is: while Outbrain and Adsense already has specific website/url tracking (and management via custom adunits which allow us to precisely track performance and hits for each user), Inread does not have this. They only just basically spit the generic code from our agent in the user page, just like their native AMP implementation (check the data-pid) and their "classic" js impression. This is perfectly fine if you only have one or a couple websites and no need to revshare. We need, instead, to manage thousands :/
They only aggregate results on their end based on the domain of the website. But our users reside on subdirectories, not subdomains, for vertical platforms. This means ALL data from ALL users come in an aggregated form - and we have a lackluster access to data reporting anyway, we have to request them in a lenghty process which could take weeks (while we need instant event access)
To overcome this for regular pages, I made a (really hacky but working nicely) JS implementation which uses MutationObservers linked to the page, which analyzes viewability, loading, unloading, ad served etc (basically all the events needed for an outstream video) linked to the specific account, fundamentally mimicking their (internal and really secret) tracking. This data gets reported to our internal adserver, which then processes the data to assign the correct revenue sharing to the user. This is working fine for regular pages where I have full control over the JS loaded.
With AMP, I cannot run the custom js nor I can serve specific tags via their native implementation. That's why I needed to run the video from a bootstrapping page, so I could do advanced tracking on that, manage exit condition and report data to our adserver.
Maybe there is a better solution here that I'm missing and not able to see, instead of using the 3P Remote. But that looked like the only solution for this specific ad format.
Thanks again! Alessandro
What's the issue?
We are trying to implement custom tracking for our hosting network which uses Teads (Inread) technology for a specific ad position, which is a supported Ad Network in AMP.
We are having success implementing all other type of ads we have on page (Adsense/Outbrain), but these ads do not require a specific tracking.
For inread, we are using a custom script on our normal, non-amp pages which manages source webiste traffic and reporting to our internal adserver.
Now, I know about remote.html custom implementation.
The problem is, if I enable the metatag and allow "teads" network to run through our custom-server ad, ALL tags on the page gets their source replaced with our customized frame via meta name="amp-3p-iframe-src"
Moreover, if I try to enable Adsense along with the banner to edit, I get a denial "3p iframe url disabled for adsense", probably because AdSense does not allow custom 3p frame serving.
What I'm trying to achieve is to load a customized ad-frame source for a SINGLE, specific tag, so we can load teads normally from there and load our custom tracking script.
It seems there is no way to scope single amp-ad request to use the meta name="amp-3p-iframe-src" custom directive, instead it's an all-or-nothing approach for the whole page.
The other solution which pops to my mind is to simply use an amp-iframe and do whatever I like on the external frame - but your policy actually restrict using iframes for ad content. This is limiting, if we are not allowed to customize specific ad positions for advanced solutions like in this case
How do we reproduce the issue?
We could add a specific data like mode="default" to opt-out from custom 3p serving (making it opt-in could break previous implementations)