Amphtml: Intent to implement: SkimLinks extension

[karolk]

Skimlinks intends to submit a PR for review with extension. The extension provides a way for publisher to use content monetization and performance tracking. (details: http://skimlinks.com/features)

The implementation will use following syntax

<amp-skimlinks data-skim-id="..." data-site-name="...">
<script type="application/json">
{
 //config
}
</script>
</amp-skimlinks>

[cramforce]

Thanks for submitting!
How would this be implemented?

[karolk]

The way skimlinks JS work at the moment is by changing the url of the clicked link if it's a known merchant url, for example http://etsy.com becomes http://go.redirectingat.com?url=http//etsy.com&params... To achieve this the extension sets up a global single event handler to observe clicks on links. There is also a call to our service, which accepts a list of unique domains linked on the page and returns a list of known merchants.
The amp component will contains an essential skimlinks implementation and bindings for the tag to accept publisher settings. I am happy to share access to our branch if you want to have a look at the actual implementation, although we are not yet ready for a PR.

[cramforce]

Thanks. That sounds reasonable in general. We do, however, feel pretty strongly about unnecessary redirects and they are bad user experience, especially on mobile.

I think it'd be worth considering if the referral info could get injected directly into URLs without the extra hop.

[karolk]

We do have an API allowing publishers to create affiliate URLs in advance of the publication, so they may chose not to deploy our JS script at all. In order to work on the page we have to use a redirection service because we work with over 18k merchants and not every publisher works with every merchant. To minimize our footprint we only create the additional hop if the url is a known merchant that works with this particular publisher. Additionally if they chose to use the JS script publishers get the benefit of link impression and conversion tracking. So on a typical page if there is not a click on a merchant url there won't be a redirection and we will not write to DOM at any point.

[karolk]

@cramforce this got backlogged, does it mean we are still OK to open a PR and it's going to be looked at? Sorry, I am new to this process, thanks.

[cramforce]

Not sure what exactly @ericlindley-g wanted to say with Backlog :)

I just missed your reply. I think if there is a server side solution, then it makes more sense to pick that. One of AMP's principles is to solve problems on the right layer of the stack prioritizing user experience over developer experience. This is sometimes painful, but it is the right thing to do in the long term.

I just posted #2934 yesterday. This may be interesting to you as it will allow avoiding the redirect if the destination is an AMP page.

[ericlindley-g]

@karolk @cramforce

I may have been overzealous with the backlog the other day :)

Sounds like this is more appropriate for "Pending 3P Implementation", so I've re-slotted it there.

[karolk]

@cramforce Hi, to clarify further. I think in theory it is possible to implement a service that doesn't require an additional redirect between the amp page and the merchant page, but at the moment we don't have this functionality. Is there something in amp, (like prefetching?) that would allow us to carry on with the redirect? Re: #2934 I think this is a great solution, but what how do we check before redirecting to the page if the ping back is guaranteed? If the destination page can't ping back then redirect is the only feasible fallback?

[cramforce]

@karolk How about using the HTML ping attribute as in <a href="…" ping="…">? I think it would be pretty easy to build a polyfill for that that works in all browsers and is as slow as a redirect in the worst case.

[karolk]

@cramforce Regarding the "side request" approach as opposed to a redirect: we think this is something that would be a significant change in how our technology works at the moment, and presumably how lot of other affiliate technology works. We put a lot of effort into making sure these redirects are as fast as possible by minimising what the code does and minimising geo latencies.

I looked into ping attribute but beside weak browser support it is also async, so it creates additional complications with ping arriving after the actual user visit or not arriving at all, which makes it hard to attribute the click correctly.

I think using something such as <link dns-prefetch="redirecting"> instead could help us minimise the slowness of the redirect?

Just to reiterate, these redirects don't happen with every click, our client-side code only affiliates potential merchant links, so the majority of clicks including internal links and non-merchants are not touched.

In a broader context we think <amp-skimlinks> component would be lightweight on the actual AMP pages because there are no layout reflows and nothing is rendered. We understand that AMP is about keeping the critical path fast but it's not always possible to control what happens once the user leaves AMP page?

[aaronskim]

Hello,

@cramforce could we get an update on this? To be clear, we don't think it's possible to reduce the number of redirects - they each are to inform a separate company in the chain about the activity, and each of them needs access to their own cookie in a very reliable manner. A typical chain will look like Skimlinks -> Affiliate network -> Retailer. Many of our publishers view the monetization of these clicks as the most important aspect of their content, so having an async or weakly supported alternative where some of these links fail (and, therefore, they don't make money) would be considered very bad by our publishers. Is there a hard rule on the number of allowed redirects? I imagine this issue is being faced by many within the affiliate ecosystem.

Thank you,
Aaron McKee
CTO Skimlinks

[cramforce]

Basically the question is: can we reset the ecosystem and find a way where monetization works but without negative impact for users.

You are the first affiliate company asking which is why we are having more of a discussion.

If there is no such way that is OKish, but we should try. It is a non-goal to simply port all the sins of our youth to AMP :)

Did we determine that a ping polyfill is not a good solution? That seems like it would work great.

[aaronskim]

Apologies for the delay in responding - we’ve been having in-depth conversations with our affiliate network and publisher partners to explore all possible solutions. The consensus from all parties is that the onping solution, with or without a polyfill, is not viable.

The reasoning behind this is:

• Fear, by the affiliate networks, publishers, and merchants, of spurious and fraudulent clicks. If the networks supported asynchronous / out-of-band click tracking, it would be possible for bad actors to generate these without real clicks being associated to them. In a realistic bad scenario, you could see bad actors injecting these en masse in ads, background content, etc. across multiple merchants or networks. These clicks are directly linked to payments - which in turn could be very bad for the ecosystem, if bad actors were present. As such, they want to control the redirect downstream.
• Fear that they would not be able to set a first party cookie and thus not be able to link a downstream sale with the clicking activity.
• Fear that the asynchronous solution would be less reliable. Our past experiences shows that out-of-band calls can see between a 5-15+% difference in counts vs. synchronous/in-line counterparts. This is a non-trivial amount of revenue for many publishers.

From our conversations, our network partners are telling us that their click trackers must be inline with the publisher’s click. Therefore the chain that must exist is publisher -> third party tracking (us, affiliate network) -> merchant landing page. We were unable to speak to all of our partners (there are in excess of 50), but we spoke to a breadth and it is safe to assume we won’t be able to universally change their behavior.

The solution we’re currently having to use and suggest, to work around not having something like this module, is for our publishers to pre-generate these 3-deep redirect links. These appear to be working fine for pages loaded via AMP, but requires measurably more work for our publishers to generate and embed these hardcoded redirects. This AMP module aims to automate that process, but the end result is basically the same: publishers embedding click redirects.

I’m very supportive of the goal to reset the ecosystem - the state of Internet standards and implementations, as well as the general bad habits present, are nightmares of epic proportions and Google is likely one of the few players that has a big enough stick to enact positive change. Given the massive interconnectedness of the affiliate ecosystem, however, this may be one of the more challenging ecosystems to change quickly, without putting fragile publisher revenue streams at risk or introducing means of operation that are prone to abuse. The aim of this module is to make it easier for publishers to fully support AMP across their content portfolio, without creating these risks and in a manner that aims to be at least as performant as their fallback scenario.

Kind regards,
Aaron

[cramforce]

The only way to combat fear is to try. If we don't than we cannot get better. There was definitely a lot of fear about AMP itself, but lots of publishers saw that it is worth trying things on mobile.

I'm glad the server side solution works for publishers. This is inline with our design principles published here: https://github.com/ampproject/amphtml/blob/master/DESIGN_PRINCIPLES.md#user-experience--developer-experience--ease-of-implementation
Basically we feel that it is cool for the publisher to invest a bit more work once if the user experience is better as a result many millions of times.

With such a workaround in place, it seems we can take our time and set up an experiment to do asynchronous click tracking. Does that sound good?

[jpettitt]

@aaronskim assuming you don't end up baking this into AMP we'd be interested in baking this into our AMP converter server side for publisher that want it and want to use use our platform. Ping me in email (jpp @ relaymedia dot com) if you'd like to discuss.

[jasti]

@aaronskim is there an update here? Were you still up for trying alternate solutions? Thanks.

[lisaskimlinks]

Thanks for reaching out @jasti. Our publisher partners continue to be frustrated at the increased effort and fragility imposed by the workaround that the rejection of this AMP module has necessitated. As it stands, they are having to hardcode the redirecting links rather than use our typically-dynamic system. We continue to stand by our belief that there are no viable alternatives to the inline redirecting approach followed by our module. If you had any further ideas to move this process along, please do let us know. Thanks.

[pdufour]

As a developer for a large media co. I'm much more in favor of the async click tracking solution.

[jpettitt]

See #9276

[pdufour]

@aaronskim any update?

[BjornB2]

Same question here. Any update?

[jasti]

@aaronskim does @jpettitt 's solution in #9276 work for you as well?
@jpettitt is this something you are planning to implement relatively soon? Thanks.

[jasti]

Closing this as routine clean-up since there hasn't been a follow up. Please re-open if you need assistance.