✨ 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