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?