✨ AMP-AD Fast Fetch InsurAds implementation

[JoseClimaco]

InsurAds is a time & attention management platform aiming to create real-time live audience of unique users, handling attention time in front of all content and ad creatives. The platform seamlessly integrates with Publishers’s Ad-Server to establish real-time audience connections, measure every attention second and maximize advertising revenue.

The time has come to update our AMP integration. We are moving from our legacy Delayed Fetch implementation to a new Fast-Fetch integration, to better align with current AMP standards.

The InsurAds implementation intentionally leverages DoubleClick core features to ensure full compliance with AMP runtime guidelines, while also extending capabilities for real-time analytics and monitoring. By building on top of DoubleClick, we avoid duplicating complex ad delivery logic and benefit from a well-tested foundation. This approach keeps our implementation maintainable and aligned with upstream AMP updates. Importantly, it is scoped exclusively to InsurAds and does not impact or modify any other implementations. Therefore, we believe the dependency is justified.

We ask for an initial code review, to guide us in the correct direction.

Thank you very much

/cc @powerivq

[powerivq]

Cookie: Please have a separate doc to describe every cookie entry being read/wrote, and their purposes. it needs to go to a review process. The reason is that you are not just writing the cookie on the publisher's page. It could also go to every AMP viewer domain.

Dependency: @JoseClimaco I understand your goal of using underlying DoubleClick functions, but Doubleclick might not be able to support your use case here. @zombifier WDYT?

Also, the way to use AmpAdNetworkDoubleClickImpl in your PR (getting the prototype and doing some mods) is way too hacky. I am afraid it is too unstable and hacky to be acceptable.

[zombifier]

I concur that this is not something DoubleClick wants to support. The extension's functionality and behavior can and will change without warning, and having it break another unrelated extension would add unacceptable maintenance burden on our part.

[JoseClimaco]

We understand where you're coming from, and we truly appreciate your feedback.

That said, we’d like to clarify a few points and offer some context for our approach:

1. Our dependency does not impact DoubleClick’s behavior or stability. We’ve designed our implementation to be fully isolated. While we do access certain methods from AmpAdNetworkDoubleclickImpl, we strictly use logic originally from A4A and we are not relying on anything DoubleClick-specific that could introduce instability or coupling. If this part isn’t clear, we’re happy to walk through it in more detail.

2. We fully accept and contain the maintenance responsibility. Any breakage caused by changes on the DoubleClick side will solely impact our extension. We are prepared to handle and fix those breakages without burdening the DoubleClick or AMP teams. That said, we believe the likelihood of breakage is low, as our implementation relies only on logic originally defined in the A4A framework. Unless there are changes to A4A itself, our extension should remain stable.

3. Publishers using the InsurAds extension do so consciously and at their own risk.
   They understand that this is a third-party solution, and we make the maintenance responsibility explicit.

4. As we understand all associated risks are confined to our side.

5. If needed, we’re happy to provide a formal declaration covering all the above.

6. If our current approach is not acceptable, we would greatly appreciate guidance on the correct path forward:
   6.1. The core logic we need already exists in the DoubleClick implementation.
   6.2. Our goal is to deliver ads via Google Ad Manager, just like DoubleClick does.
   6.3. Duplicating the logic feels like a poor long-term choice in terms of maintainability.
   6.4. We want to comply fully with AMP best practices and remain good ecosystem participants.

Please let us know how best to move forward, we're open to collaboration.

Thank you @powerivq and @zombifier

[JoseClimaco]

@powerivq

Regarding the use of cookies:
Our intention is to write cookies only on the publisher's domain and never on AMP viewer domains.

We're using the setCookie and getCookie utilities from the AMP cookie module, along with highestAvailableDomain. Based on the documentation, this approach seems safe for our use case.

However, if there's a risk we're not seeing, please let us know. Would you recommend explicitly setting the domain instead of relying on highestAvailableDomain?

We're also aware of the allowOnProxyOrigin flag, but we're not using it and don't have any use case that requires it.

If there's something we're missing, we'd appreciate your guidance.

[powerivq]

@JoseClimaco We are very pleased with your generous undertaking, but I do not think this model could work. I can explain more why it is not desirable on our part. We have various mechanisms to track errors (e.g. exceptions) in the entire AMP runtime. If something fails (including in your extension), it is going to affect our entire release process, and require resource from both ends to figure out what happened. It probably delays what Doubleclick wants to do.

Therefore, we are enforcing a high level of code quality for anything checked in. This current implementation is too hacky to be comfortable.

I suggest you look at doing a 3p implementation. There are many vendors serving Doubleclick ads through a 3p integration (I see you already have one)

Alternatively, if you really want a fast fetch implementation, you can implement whatever logics yourself.

As to cookies, an AMP page could be served from a cache. The origin is the cache's origin, not publisher's. (https://amp.dev/documentation/guides-and-tutorials/learn/amp-caches-and-cors/amp-cache-urls) Whatever cookie you are setting is affecting these domains. Therefore, it has to go through proper vetting process.

[JoseClimaco]

@powerivq Thank you for your answer and assistance in guiding us in this process.

Not being an option, let's move forward with a different approach.

The 3p implementation we already have is not the way, due to all its limitations and the features we must provide.
We work with publishers all over the world, and they are demanding that we completely support AMP in every feature we already have in our web implementation, using the GPT api, besides other things, like header bidding integrations, etc.

Unfortunately, for instance, we don't see a way in AMP, outside the doubleClick extension, to read information about what is served (line item, creative, size), among other things we require to deal with.

Following your own words, when you say we can implement any logic ourselves, would it be acceptable for us to implement our extension starting from a DoubleClick replication? We are fully aware that this will bring us a huge maintenance effort in the future.

That being said, if this way is still not acceptable from your perspective, can you please provide us with further assistance on how we can make this happen, to meet our customer requirements? Please note that they want to use Google Ad Manager as their ad server; therefore, the requirement to keep all the DoubleClick logic.

We are being completely transparent with this because we cannot afford to take the risk that it won't be approved for any other reason, even when no dependencies exist at all.

[powerivq]

You have complete access to the 3p iframe, therefore you should have access to the creative and size of the container. What exactly do you want to access? The DOM itself? @JoseClimaco

[JoseClimaco]

@powerivq Thank you for your reply.

You're right that we have full control over the 3p iframe, and we can access and measure the content we serve there. However, our requirements extend beyond what is possible in the current 3p implementation.

Specifically, we need support for features that the A4A / DoubleClick AMP extension offers, such as:
•⁠ ⁠Support for rtc-config header bidding integrations
•⁠ ⁠Full integration with amp-analytics, including vendor-based reporting

These capabilities are crucial for our publishers who use Google Ad Manager and expect parity with our web implementation.

For example, we previously had a publisher unable to adopt our AMP solution because we didn’t support amp-analytics vendors. Overcoming these limitations is difficult without replicating behavior already implemented in the DoubleClick extension.

We want to fully follow AMP best practices, but we also need to meet our customers requirements.

In summary, this is why we want to move away from a 3p implementation and focus on a Fast Fetch based approach.

[powerivq]

@JoseClimaco You can look at freestar as an example of doing rtc and using doubleclick to serve ads. I am not sure what amp-analytics integration means here. What are you trying to achieve? DoubleClick extension does not do anything special with amp-analytics.

[JoseClimaco]

@powerivq Thank you again for the feedback. We understand the boundaries you're trying to maintain.

We want to emphasize that InsurAds is not a header bidding platform like Freestar. We’re not sourcing demand or rendering alternate creatives. Instead, we enhance GAM delivered ads with attention tracking, analytics, and real-time optimization features.

Regarding amp-analytics, our goal is to support all analytics vendors that are available in AMP, so publishers can use their preferred analytics integrations seamlessly with our extension, just as they can with DoubleClick.

For rtc-config, we want to support every vendor listed in AMP callout-vendors.js, ensuring full compatibility with header bidding and real-time configuration.

Let me be transparent and summarize a few key points here:

• 3p doesn't work for us; it doesn't offer every functionality that Fast Fetch supports, like missing rtc-config support and amp-analytics support.
• Why do we need Fast Fetch, including some DoubleClick functionality?
  • Our main requirement is to provide publishers with a drop-in replacement for DoubleClick that maintains the same features.
  • Google Ad Manager Ad Request logic (Already implemented DoubleClick)
  • rtc-config logic (Already implemented in Fast Fetch)
  • amp-analytics logic (Already implemented)
  • any future features or extensions

Ideally, we think that exploring a new supported pattern for GAM add-on networks that rely on the core AMP ad lifecycle would be beneficial to the AMP ecosystem.

We’re committed to doing this the AMP compliant way, and we’re happy to lead the implementation if such a pathway can be outlined.

As a Google Certified Publishing Partner, it's important for us to offer our implementation in AMP, like we do in Web, Mobile, and others. We have more than 1000 Premium Publishers that want to add-on our new capabilities to their GAM and AMP implementation and we kindly request that you can accommodate our implementation, that obviously will need to be validated and used by the Publishers one at a time which will give you all the comfort that we are taking this on the right track.

Looking forward to hearing from you,
Thanks in advance.

[JoseClimaco]

@powerivq @erwinmombay any updates? It is really important for us to get some feedback from you. Thank you.

[erwinmombay]

@JoseClimaco ill follow up. @powerivq is currently on leave so I need to get another ads expert to help me review

[powerivq]

@JoseClimaco

As to amp-analytics, I am confused on what exactly you want to do that you can't do today. Do you want to track web elements within the creative? That should be done by the creative itself, not the publisher or the extension. An AMPHTML creative could have its own amp-analytics tracking elements.

Implementing a fast fetch extension is intended to improve ads serving speed by generating your ads request URL early and requesting early. The extension is not intended to enable full access between the parent page and ads iframe, or to allow modification of creative, or device fingerprinting. DoubleClick extension, for example, only fetches the creative and do nothing further but to render it. It seems to me that you are still intending to serve ads via 3p iframe, so I do not see why you need to use a fast fetch extension. Perhaps you can create your own ads request backend and you can serve whatever creative within an iframe of your response, without resorting to use of fast fetch.

[cburaca]

Hi @powerivq ,

I'm @JoseClimaco's colleague from the InsurAds team.

We don't do any creative manipulation - we just need a more granular and dynamic control on how and when the refresh happens, because we measure ad overexposure.
After creative rendering, we do not do any modification - we only identify and measure!

We are Google Certified Publishing Partners (GCPP) - we are fully committed to adding value to all!

As explained above, our product aims to extend doubleclick, adding time and attention measurement features, with overexposure control, offering both publishers and advertisers several benefits.

Basically, we need to serve ads from GAM just like doubleclick does, but also to:
•⁠ ⁠identify served line item ID, creative ID and size
•⁠ ⁠participate in the header bidding process through rtc-config (and this is only possible via fast-fetch)

Ideally, this would be made extending doubleclick.
Since this is not an option, how do we achieve this?

[powerivq]

@cburaca Hi,

Thank you for the detailed explanation of your requirements. I think 3p implementation remains your best path forward.
Fast fetch extensions are not intended to host heavy vendor-specific ad logic. It is designed for early ad request generation and improved loading performance - not as a platform for extensive tracking, analytics, or custom ad manipulation. By manipulation, I do not mean anything negative. You are even free to implement a fast fetch extension, and make the ad request to your own backend, and you can do these things on your 3p iframe (albeit with slightly worse performance).

[cburaca]

@powerivq thank you for your reply.

We already have a 3p implementation and it does not deliver the features customers demand.

As suggested above, we will submit a new PR with our own implementation - no doubleclick dependencies - though, of course, some logic might be similar.

You'll have no worries about breaking changes and all the maintenance hard work will be up to us.
This way, publishers can freely choose which extension to use.
In case ours cause any unpredictable impact on their pages, they will always have the doubleclick fallback.

Thanks.

[powerivq]

@cburaca You are more than welcomed to implement an own a4a extension. That being said, please also take other comments into account when you do so. A fast fetch extension is meant to let you construct and send the ads request early, not for any other purposes (https://amp.dev/documentation/guides-and-tutorials/develop/monetization/ and https://www.publift.com/blog/amp-ads-a-complete-guide-for-digital-publishers)

If you want to do analytics, that need to be done either completely within 3p iframe or you can use amp-analytics by having publisher placing amp-analytics tag in the AMP web page (not inserted by your extension). The way this draft is doing it (extensions/amp-ad-network-insurads-impl/0.1/engagement-tracking.js) by messaging back-and-forth is not the intention of allowing a fast fetch extension.

I initially thought extensions/amp-ad-network-insurads-impl/0.1/realtime-manager.js was a real-time config, but it seems that I am wrong. I am not sure what this websocket connection is used for, but it does not seem to fit our model of "making the ads request and rendering it in an iframe and it's done."

I felt you went much much beyond what a fast fetch extension is intended for. If you have doubt, you can reference to other networks' implementation (there are a few). Again, the only intention of a fast fetch extension is to create the ads request early and we will render it in the iframe when the user comes to it. If you want to do ads refresh or your own analytics? Great, you just have to implement it within your iframe, and we do not even need to review your code. You have 100% control. A fast fetch extension is not intended to be a replacement for a full ads tag. It is not the case for DoubleClick/Adsense either.