With traditional tracking, a click on an ad takes a user to a tracking server first, which then redirects the user to the landing page (potentially via other additional trackers). These tracking redirects can cause longer page load times, which may worsen the user experience and adversely affect conversion rates.
Parallel tracking is a different way of handling custom click tracking. It uses the sendBeacon browser function to perform tracking in the background while accelerating the user to their final destination. This helps to reduce the number of visits that would otherwise be lost when a user clicks on your ad but never reaches your landing page (because the user navigates away before the redirect from your tracking URL is completed).
Parallel tracking is not yet supported by all browsers. If someone views your ad on a browser that doesn't support parallel tracking yet, Google will revert to sequential tracking.
This article explains how Comparison Shopping Services (CSSs) in Europe that show products in Shopping ads on behalf of merchants can implement parallel tracking.
How parallel tracking works
Parallel tracking sends customers directly from your ad to your final URL, while click measurement happens in the background (without sending the customer to the tracking URLs first).
Here's what parallel tracking looks like:
- Customer clicks your ad.
- Customer sees the merchant landing page.
At the same time, in the background:
- The Google Ads click tracker loads.
- Tracking URL loads.
- If you use more than one click tracker, additional redirects may load.
Without parallel tracking, customers go through one or more redirects after clicking your ad before they reach the merchant landing page. This means that it takes longer for customers to reach the final landing page.
Here's what tracking looks like without parallel tracking:
- Customer clicks your ad.
- The Google Ads click tracker loads.
- Tracking URL loads.
- Possible additional tracking URL loads.
- Customer sees the merchant landing page.
How to implement parallel tracking
Implementing parallel tracking may require changes to your product data, your tracking setup and potentially to the website of the merchant for whom you place ads.
Product data
Adjust the following URL attributes in your product data:
Link [link]: This URL is the final merchant landing page on the merchant's domain. It is used for Google's crawls and other checks. Do not include any tracking parameters here that are relevant for reporting or billing.
Ads redirect [ads_redirect]: This URL is where the customer is sent directly after clicking on the ad. It must lead to the same domain as the link [link] attribute. Include tracking parameters here that you want to send to the merchant website. Avoid additional tracking parameters that the merchant may not expect, because they could lead to issues when loading the merchant page.
Tracking template
Use a tracking template to define where the tracking in the background should lead. You can include ValueTrack parameters to share information with your tracking server. For Shopping ads, parameters like the merchant ID and the product ID are also available.
Tracking server
Parallel tracking only supports server-level redirects. In addition, every URL in the tracking redirect chain must support HTTPS. The tracking sequence will terminate at the previous URL when HTTP or on-page redirects like JavaScript or HTML are encountered. There will be no impact on the user experience, as tracking happens in the background, but trackers that don't get called will not receive click tracking information.
To ensure that parallel tracking works correctly:
- Ensure that your tracking server uses the HTTPS protocol, and that any internal redirects that you have set up use HTTPS.
- Avoid any redirect mechanisms that use on-page methods, like a JavaScript redirect, as these won't work. If you use any such redirection mechanisms in your tracking redirect chain, they need to be changed.
Auto HTTPS rewrite
While we don't have control over the subsequent redirects, Google Ads will always rewrite the first tracking call to HTTPS if it's not entered as such. The final URL can use either HTTP or HTTPS. However, ensure that your server is set up to handle the request if the protocol is switched to HTTPS for any of your URLs entered in Google Ads.
For example, if your tracker URL is tracker.example.com, then it should respond to both http://tracker.example.com and https://tracker.example.com.
Per-click IDs
Some tracking servers include a per-click ID when redirecting to the landing page so that the parameter can be read (and stored) by the website for joining various measurements. This is not possible with parallel tracking, since the call to the tracking server does not forward to the website.
As a workaround, you can turn on auto-tagging in the customer account. When auto-tagging is enabled, the Google Click Identifier (GCLID) parameter will be added to the end of the landing page URL and tracking template URL during serving time. This enables both on-page tags (for example, Google Analytics) and tracking servers to process it. This parameter can be used as a common key to join traffic information.
In addition to auto-tagging, we have launched a new {gclid} ValueTrack parameter. If you currently have a parameter that you use for inserting your unique identifier, you can use {gclid} as the value instead to potentially reduce the amount of changes required to your website. For example, if the final URL or tracking template in Google Ads contains something like partner_ID=[Dynamically-generated click ID], you can now update it to partner_ID={gclid}.
URL recomposition
At serving time, parameters attached to the {lpurl} ValueTrack parameter and its variants in your tracking template field will be parsed based on encoding rules and appended to the landing page call. In addition, when parallel tracking is applied, the {lpurl} parameter in the tracker call is replaced with a substitute URL that looks like https://google.com/asnc/dGVzdA or similar (the exact URL will vary).
Substituting {lpurl} with a Google substitute URL ensures that your webpage doesn't get pinged twice (once from the customer's click, and again from the parallel tracking redirect). The tracker should continue to redirect to this substitute URL as it would normally handle the {lpurl} ValueTrack parameter. The Google substitute URL will return an HTTP status code 204 upon redirection.
If your tracker selects the redirect URL based on an ID passed on, ensure that the redirect leads to the same page as the ads redirect [ads_redirect] URL or change the tracker behaviour such that it redirects to the URL passed on in the {lpurl} parameter instead.
Merchant website
If you change the parameters sent to the merchant website, work with the merchant to ensure that they are processed correctly and don't create issues when loading the merchant landing page.
Consider the following example:
| Merchant Center account | |
| Merchant ID | 99887766 |
| Product data | |
ID [id] |
p123v789_b |
Link [link] |
https://merchant.com/product123?variant_id=789 |
Ads redirect [ads_redirect] |
https://merchant.com/product123?variant_id=789&ref=mycss |
| Google Ads setup | |
| Tracking template | https://redirect.com?url={lpurl}&merchant={merchant_id}&product={product_id} |
| Calls where parallel tracking is supported | |
| Navigation | https://merchant.com/product123?variant_id=789&ref=mycss |
| Parallel tracker call | https://redirect.com?url=https%3A%2F%2Fgoogle.com%2Fasnc%2FdGVzdA%26 variant_id%3D789%26ref%3Dmycss&merchant=99887766&product=p123v789_b &gb=1 |
| Calls where parallel tracking is not supported | |
| Browser call | https://redirect.com?url=https%3A%2F%2Fmerchant.com%2Fproduct123% 3Fvariant_id%3D789%26ref%3Dmycss&merchant=99887766&product=p123v789 _b |
| Sequential hop | https://merchant.com/product123?variant_id=789&ref=mycss |
Note that Google adds a parameter 'gb=1' to parallel tracking calls, allowing your tracker to identify them.
How to test your parallel tracking implementation
To test your implementation, proceed as follows:
- Decide where you'd like to test your implementation. Testing can occur for a particular campaign, ad group or product group. You may also create an entirely new campaign for testing purposes.
- Add '{_beacon}=true' to the respective tracking template. When adding to a campaign, use campaign settings. When applying to an ad group or product group, add the tracking template by adding the tracking template attribute column.
- Check your logs to see if the tracking template is receiving pings. If the tracking has the parameter 'gb=1' then it has been executed in the background and is working as intended.