Migrating to Conversion Tracking v2


Implementing Conversion Tracking consists of two parts: storing and returning the rwg_token. These remain the same but to be compliant with Conversion Tracking v2 you must now return a new value: merchant_change.

Changes to persisting the token

When persisting the token, you will now be required to store the merchant associated with the action link. This is typically done by matching the merchant with the corresponding merchant_id.

The following is an example of device level conversion tracking, storing these values in a web browser using a 1st party cookie. This example assumes you have parsed the token value into a variable and have implemented logic storing the merchant_id. To use this example, you need to update rootdomain with your domain. This suggested approach may not work for everyone so partners are free to adjust or implementation their own logic as they see fit.

  if (typeof rwg_token !== 'undefined') {
    merchant_id = // Write your own logic here assigning the merchant id value
    document.cookie =
    "_rwg_token=" + rwg_token + ";_merchant_id=" + merchantid + ";max-age=2592000;domain=rootdomain.com;path=/";

Changes to Sending Conversion Data

When a user completes a conversion event, The post body should be a JSON encoded object with a new boolean value merchant_change.

  "conversion_partner_id": <partnerId>,
  "rwg_token": <rwg_token_val>
  "merchant_changed": 1|2

The previously stored merchant_id is used to determine if the merchant that triggered the conversion event is different than the original merchant. Once you've determined whether the merchant has changed, you'll return the appropriate merchant_change value using the following table.

Merchant Change Value Requirement
1 This value should be used when a user has left the original merchant's website and completed a purchase through your platform with a different merchant
2 This value should be used when the customer completed a transaction through the original Entity (Merchant).

You are required to provide a valid rwg_token when sending a conversion event. For testing purposes, use the following test token in both environments until you are ready to launch:


When making the request, use the following endpoints that correspond with your environment:

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

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 Google 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 for the same merchant in the same session(Merchant Change Value = 2 )
  • A user follows a place action link and then returns from a different channel within the 30 day window to place an order for the same merchant. ( Merchant Change Value = 2 )
  • 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. ( Merchant Change Value = 1 )

Additionally, Google expects 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.