Way to condition amp-auto-ads on amp-access

[kushal]

The amp-access-scroll extension is used by our partners to hide ads depending on the result of an amp-access cal by surrounding advertising blocks in amp-access conditionals.

<div class="amp-ad-container" amp-access="NOT scroll.scroll">
  <amp-ad... >
</div>

However, we have now have a partner using amp-auto-ads, which doesn't provide any points of control where we can similarly hide ads for Scroll users.

We're happy to help with implementation if needed, but we could use some guidance on what is the most idiomatic path forward.

[dvoytenko]

An interesting case. @lannka would you say that initializing auto-ads from buildCallback is not correct? Or should auto-ads understand access restrictions inside the buildCallback?

[kushal]

Hi! We'd love some ideas here!

…

On Tue, Mar 3, 2020 at 9:53 PM Dima Voytenko ***@***.***> wrote: An interesting case. @lannka <https://github.com/lannka> would you say that initializing auto-ads from buildCallback is not correct? Or should auto-ads understand access restrictions inside the buildCallback? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#27068?email_source=notifications&email_token=AAA2XNBYDQTDT2MUSHG27BDRFXUF5A5CNFSM4LACDUJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENWOYWA#issuecomment-594340952>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2XNH3GZQWITP7HTJ6A6TRFXUF5ANCNFSM4LACDUJA> .

[dvoytenko]

/cc @calebcordry @jpettitt As a starter, can we arrive at the conclusion whether this case fits well? IMHO, this is a very clear convergence here. Auto-ads fits very well with amp-access/subscription concepts. We just need to see how this can be configured and implemented. What are your thoughts?

[jpettitt]

Had a quick chat with Dima and Caleb. What we came up with is:

Add something like <amp-auto-ads [access expression?]> (and an equivalent for amp-subscriptions. We expose a service from access and subscriptions and have have amp-access-auto-ads call it with the expression. The service promise will resolve with the result of the expression once the access/subscriptions entitlement calls resolve. From there the ads extension will know if it can render.

We'd have to limit the expression to one that resolves to a bool and we'd have to figure out how to handle amp-access-scroll and amp-subscriptions on the page at the same time but those are both solvable.

It might make sense to add this to the base amp-ad extension too as it would be cleaner than just wrapping the ad in a conditional.

@calebcordry @dvoytenko @kushal WDYT?

[dvoytenko]

I'll see what @calebcordry has to say. But I think this makes a lot of sense. I believe amp-access and subscription-display already resolve to boolean, so that fits as well.

[calebcordry]

SGTM. We can either block the config request or the ad creation on the result of the service promise. If we block on creation, ads-enabled users would see the creatives more quickly (more revenue etc) but the ad networks might not want to calculate the placements for the population of users that will never see ads. I can run it by our partner ad networks and see what they think. They may already be doing something similar for the non-amp world.

[dvoytenko]

Thanks @calebcordry. Good point about placement-vs-creation latency. Let's confirm with the providers and see what they think. But I think generally everyone expects that the placements might not actually always take place. But, certainly, let's confirm.

[kushal]

This plan sounds awesome, thanks! Let us know if we can help.

[dvoytenko]

@calebcordry @lannka How would you recommend we proceed here? I'd like to see if we can keep it moving.

[dvoytenko]

/to @lannka to try the display/layoutCallback approach.