Step 3: Conversion Tracking

Implementation

Summary

There are three pieces to a conversion tracking implementation:

Collecting the rwg_token from the landing page / app entry point.
Persisting the rwg_token for the appropriate attribution window
Sending a conversion event at checkout

This conversion tracking implementation does not require you to use Google Analytics or any other 3rd party javascript.

Before beginning work on your conversion tracking implementation, you should decide if you're going to track conversions at the device level or user level:

The device level includes using browser cookies, local storage, app local storage, or any other method that can persist the token for the 30 day attribution window. Because the token would be stored locally on the user’s device, if the user changes the device they are using, clears their local storage/cookies, or is using a private browsing or incognito mode the conversion event may not be properly attributed. When using the device level conversion tracking, you must re-implement this across every supported surface (including mobile).
The user level includes persisting it in your application database, through a server-side analytics system or other server-side systems. Because the token would be stored on the server side, if the user changes the device they are using, clears their local storage/cookies, or is using a private browsing or incognito mode the conversion event will still be attributed once the user logs back in. When using user level conversion tracking, depending on your system’s architecture you may be able to implement this once on your server side and reuse it across all supported surfaces.

Collecting the `rwg_token`

Each time Google surfaces an action_link you have provided through the Feeds, that url will be modified to include a unique query parameter: rwg_token. The rwg_token value is an encoded string which contains some metadata about the link the user clicked. You will store this token, and pass it back as part of the conversion event.

On each landing page / app entry point you must parse the value set for the rwg_token query parameter and store it. Requirements for storing this parameter are described in the step, Persisting the rwg_token.

An example for how this token can be parsed for device level tracking through the browser is included below. Alternatively, you could collect this token on the server side when responding to the request:

<script>
  var query = location.search.substring(1);
  var params = query.split('&');
  var rwgToken = undefined;
  for (var i = 0; i < params.length; ++i) {
    var pair = params[i].split('=');
    if (pair[0] == 'rwg_token') {
      rwgToken = decodeURIComponent(pair[1]);
      break;
    }
  }
</script>

Persisting the `rwg_token`

Note: Persisting the rwg_token is key to correctly implementing the required attribution window. For more details on the attribution requirements see the section Conversion Attribution Requirements below.

You will be required to persist the rwg_token URL parameter, which will be appended to all action links provided by you, for a total duration of 30 days. The value of the rwg_token should be stored and returned without any edits. If there is an existing token persisted from a previous visit, the old token should be replaced, and the 30 day window for storage should be reset.

When persisting the token, you may either store the token at the device level or at the user level:

The device level includes using browser cookies, local storage, app local storage, or any other method that can persist the token for the 30 day attribution window.
The user level includes persisting it in your application database, through a server-side analytics system or other server-side systems.

Below is an example of device level conversion tracking, storing this token in a web browser via a 1st party cookie. This example assumes you have parsed the token value into a variable as in the example above. To use this example, you will need to update “rootdomain” to your domain.

<script>
  if (typeof rwg_token !== 'undefined') {
    document.cookie =
    "_rwg_token=" + rwg_token + ";max-age=2592000;domain=rootdomain.com;path=/";
  }
</script>

When using user level conversion tracking the rwg_token should be stored on the server and associated with the user.

Sending Conversion Data

When a user completes a transaction which is attributable to a Google Place Action link, you must send an HTTP POST request to the conversion endpoint. There are two endpoints, one for the production environment and one for the sandbox environment.

Production: https://www.google.com/maps/conversion/collect
Sandbox: https://www.google.com/maps/conversion/debug/collect

The post body should be a json encoded object in the format:

{
  'conversion_partner_id': partnerId,
  'rwg_token': <rwg_token_val>
}

In both the sandbox and production environments you will be required to provide a valid rwg_token when sending a conversion event. For testing purposes in the sandbox environment you may use the following test token.

AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==

Note: In production you should not send conversion events that are not attributed to this integration. Be sure to check for a valid and unexpired rwg_token value before sending the event.

A full example of device level conversion tracking (using a cookie on the user's device) in javascript of how to make this post request is included below:

const partnerId = XXXXXXXXXX;
const endpoint = `https://www.google.com/maps/conversion/collect`;

const rwgTokenCookie = document.cookie
  .split('; ')
  .find(row => row.startsWith('_rwg_token='));

if (typeof rwgTokenCookie !== 'undefined') {
  const rwgTokenVal = rwgTokenCookie.split('=')[1];
  fetch(endpoint, {
    method: "POST",
    body: JSON.stringify({
      conversion_partner_id: partnerId,
      rwg_token: rwgTokenVal
    })
  });
}

When using user level conversion tracking, you should retrieve the token which is associated with the user (regardless of the surface they are on) from your server side storage mechanism and send the token using the same production or sandbox endpoints.

Note: Conversion events can be sent from a web or app client, or from the server. You can make this decision according to your needs and according to where the token is stored, as long as a conversion event is sent exactly once per conversion, and includes a valid rwg_token value.

Conversion Attribution Requirements

Google’s required standard for conversion attribution is a 30-day attribution window for any interaction with a place link, at any store.

This attribution window means that we would expect a conversion event to be sent in any of the following scenarios:

A user follows a place action link and places an order in the same session
A user follows a place action link and then returns from a different channel within the 30 day window to place an order.
A user follows a place action link and then places an order at a different store, either within the same session or a different session within a 30 day window.

Additionally, we expect conversion events to be sent from all surfaces a user can land into from a place action link. Including:

Desktop or mobile web applications
Mobile apps, either through an app deep link or a registered app-intent for your domain

If the token is stored at the user level (see persisting the token), it is expected that you provide cross-device attribution. That is, a user who follows an action link from the desktop and then completes the transaction on mobile (using the same user account), should trigger a conversion event.

If the token is stored exclusively at the device level, such as in browser cookies, it is not expected that you provide cross-device attribution. In this case, each device would have a separate token persisted if the user had followed an action link on that device, and each device would follow the attribution rules separately.

Step 2: Feeds

Step 4: Pilot and Launch