Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Call Tracking Vendors #5276

Closed
chrisdesrochers opened this issue Sep 28, 2016 · 24 comments

Comments

Projects
None yet
@chrisdesrochers
Copy link

commented Sep 28, 2016

We utilize call tracking on our pages to track conversions that occur via phone. This is also a critical need for mobile landing pages. Current call tracking providers usually require the inclusion of an external JavaScript library which rewrite the phone numbers on a page with a unique tracking number. Requesting a component which standardizes call tracking implementation in AMP similar to how amp-analytics is implemented.

Example providers:

@taf2

This comment has been minimized.

Copy link

commented Sep 28, 2016

It looks like the amp-analytics package might already be compatible with at least CallTrackingMetrics - working on this now to see if that's the case. [edit] sorry for mis-understanding it looks like the amp-analytics package only allows sending requests not loading additional scripts. so it would be necessary to make modifications.

@taf2

This comment has been minimized.

Copy link

commented Sep 28, 2016

If anyone is interested I created a branch and started on adding support for CallTrackingMetrics. I believe this is a generic enough start so the other vendors could use a similar approach and we'd still need to add some test coverage before this would probably be accepted. Additionally, I hacked into the preconnect view code to inject our scripts this may or may not be okay.

here's my initial work: https://github.com/taf2/amphtml/tree/master/extensions/amp-calltracking

If this looks good enough - I'm happy to turn this into a pull request as well.

@rudygalfi

This comment has been minimized.

Copy link
Contributor

commented Sep 28, 2016

cc @cramforce @avimehta

Looking at the design of the code, one concern I have is that this looks like it permits arbitrary 3P script execution, which is something that's now allowed in AMP except through sandboxed iframes. AMP must be able to have awareness of the performance characteristics of the scripts that run directly on the main page.

The design of amp-analytics enables an external request to fetch a config, but then AMP itself handles all of the instrumentation. Is there any way to achieve that here? I'm thinking that the amp-calltracking extension could take a config endpoint URL, which will return the transformations that need to be applied on the page. What HTML transformations are involved to achieve the tracking? E.g. is this updates to the values of certain tags?

@taf2

This comment has been minimized.

Copy link

commented Sep 28, 2016

@rudygalfi - yeah that makes sense perhaps we could have call tracking providers publish a manifest of some sort that determines the page transformations to run? The important thing to keep in mind is most vendors would have proprietary solutions. They all generally work the same way - issue a unique tracking number given either a landing or referring URL pattern. Some require an additional script or HTTP request to load after evaluating the page state to determine the (tracking) phone number to display. Many of them will do a full DOM traversal to locate a specific (target) phone number to replace. Others might provide a DOM hint to indicate which element contains the phone number. In a lot of ways call tracking dynamic number insertion is similar to what services like Optimizely/VWO do by modifying the page dynamically. It's possible it might work to more generally group a call tracking solution provider with general A/B testing software solutions like Optimizely and VWO...

It would IMO be very hard to generically cover these use cases without loading an additional third party script.

@rudygalfi

This comment has been minimized.

Copy link
Contributor

commented Sep 28, 2016

Thanks for the details @taf2. Yeah, to get this working in AMP, it sounds like we'll definitely need to explore a new approach than what's used today.

Once a design is ready that doesn't involve 3p script execution on the main AMP page, I'd suggest moving this discussion to a new Intent to Implement issue so we can flesh out the finer points of the extension behavior.

@cramforce

This comment has been minimized.

Copy link
Member

commented Sep 29, 2016

All sounds good.

Is the unique ID typically defined on the client side? If it is server
side, one could possibly just standardize the protocol that is used to talk
to the respective providers.

On Wed, Sep 28, 2016 at 9:57 AM, Rudy Galfi notifications@github.com
wrote:

Thanks for the details @taf2 https://github.com/taf2. Yeah, to get this
working in AMP, it sounds like we'll definitely need to explore a new
approach than what's used today.

Once a design is ready that doesn't involve 3p script execution on the
main AMP page, I'd suggest moving this discussion to a new Intent to
Implement issue so we can flesh out the finer points of the extension
behavior.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5276 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT28ixKdE4BRKobyUjtfFRCGKITBKks5qupxzgaJpZM4KIW6k
.

@ericlindley-g ericlindley-g added this to the Pending 3P Implementation milestone Oct 5, 2016

@lannka

This comment has been minimized.

Copy link
Contributor

commented Nov 29, 2016

If ID is from server side, amp-list can do the job. (we should rename amp-list to amp-remote-render or something).

@jasti

This comment has been minimized.

Copy link
Collaborator

commented Jan 5, 2017

@taf2 did you get a chance to open a new ITI/ approach without 3P JS execution on the AMP page? Thanks.

@taf2

This comment has been minimized.

Copy link

commented Jan 5, 2017

@jasti, sorry I'm not following can you elaborate on this? Really I think to support Call Tracking in AMP pages we'll need AMP pages to support services such as Optimizely. The methods we used to update phone numbers on a website is very similar to dynamic content changes... This might not be compatible with the design goals of AMP unfortunately...

@cramforce

This comment has been minimized.

Copy link
Member

commented Jan 5, 2017

@taf2 Do you need anything besides:

  • change a text string (aka the phone number)
  • track clicks (to send analytics beacons on clicks onto tel: links?
@taf2

This comment has been minimized.

Copy link

commented Jan 5, 2017

@cramforce yes, i can attempt to summarize

  • tracking page position
  • tracking visibility of dom elements
  • tracking text selection
  • dom changes such as text color and visibility
  • alt, href attributes
  • there's more...
@cramforce

This comment has been minimized.

Copy link
Member

commented Jan 5, 2017

@taf2 Should be either supported by amp-analytics or can be added as individual feature requests.

@jasti

This comment has been minimized.

Copy link
Collaborator

commented Jan 10, 2017

@rudygalfi are these FRs something you'd be able to help with for amp-analytics or should I take a crack?

@rudygalfi

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2017

@jasti If you could file the individual FRs, that would be helpful.

@cramforce

This comment has been minimized.

Copy link
Member

commented Jan 12, 2017

My proposal would be to build something like

<amp-call-tracking config="https://vendor.com/call-tracking?user_id=123"><a href="tel:123-500-4568">123-500-4568</a></amp-call-tracking>

The vendor config would supply the replacement phone number and an amp-analytics config.

An alternative would be to just make this amp-list based. My intuition is that this is a frequent enough use case to warrant a special purpose extension. CC @dvoytenko

@cramforce

This comment has been minimized.

Copy link
Member

commented Feb 3, 2017

@cramforce

This comment has been minimized.

Copy link
Member

commented Feb 3, 2017

Filed #7340 to track implementation.

@jridgewell

This comment has been minimized.

Copy link
Member

commented Feb 14, 2017

Closed by #7493?

@alanorozco

This comment has been minimized.

Copy link
Member

commented Feb 15, 2017

PR is #7493 and documentation is here.

@bpaduch

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2017

@alanorozco - Is this component still "in development"? I tried to use it but the JS wasn't on the CDN.

@alanorozco

This comment has been minimized.

Copy link
Member

commented Mar 15, 2017

@bpaduch Will update documentation once the component has made it into production, possibly within a couple of weeks :) Thanks.

@bpaduch

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2017

@alanorozco - friendly ping; it's still not in the JS - validation fails.

Nevermind ... works now.

@joshcp

This comment has been minimized.

Copy link

commented Jul 20, 2017

@chrisdesrochers did #7493 solve this for you? Specifically interested in implementing CallTrackingMetrics in AMP.

@taf2

This comment has been minimized.

Copy link

commented Sep 15, 2017

@joshcp,@chrisdesrochers we have support now for AMP with CallTrackingMetrics

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.