> [!NOTE] > **Note:** Conversion tracking last updated on February 2, 2024. If you have any questions about the changes, reach out to your Google representative. ![Figure 2: Conversion Tracking Overview](https://developers.google.com/static/actions-center/images/conversion-tracking.png) **Figure 1.** Conversion tracking overview ## Overview Conversion tracking keeps the track of conversions initiated by Google through one of our [Action Center integrations](https://developers.google.com/actions-center). It helps to keep your integration healthy and running, as it can influence the ranking on certain pages. Each time Google generates an `action_link`, the specific URL is modified to include a unique query parameter: `rwg_token`. You can store the token and return the appropriate values when a user completes a booking. To complete the integration, follow these steps: 1. Parse and store the `rwg_token`. 2. Parse and store the merchant information. 3. Return the `rwg_token` and the `merchant_changed` values. 4. Test and verify the conversion tracking. > [!NOTE] > **Note:** The standard integration procedure requires partners to implement conversion tracking for performance measurement, with technical steps detailed in the section described later. Be advised that conversion tracking implementation is optional for partners in the [healthcare](https://developers.google.com/actions-center/verticals/appointments/redirect/policies/platform-policies#supported_merchant_types) vertical based on business needs ## Parse and Store the `rwg_token` To complete the integration you need to collect and store the `rwg_token` for up to 30 days of the initial Google referral. The `rwg_token` value is an encoded string, which contains metadata about the link and the merchant information that generated that `action_link`. > [!IMPORTANT] > **Important:** No personally identifying information is stored or encrypted. ### Parse the Token When a user is directed to your booking page, a new `rwg_token` is appended to the URL provided. In your booking page, you need to parse the token value. The following example shows how the `rwg_token` is parsed for device-level tracking through a browser. const rwgToken = new URLSearchParams(location.search).get('rwg_token') || undefined; > [!IMPORTANT] > **Important:** Google recommends you store the token as a decoded value in your cookie, as browser cookies have specific uses for special characters such as `=`. In any case, make sure that the decoded version is sent in the conversion RPC and it includes any special characters such as `=`. ### Store the Token When you store the `rwg_token`, you can implement conversion tracking at two different levels: - Device-level - User-level You can store the token at any level, but **you must store the token for 30 days after the initial referral**. The following example shows the device-level conversion tracking. You can store the token values in a browser with the first-party cookie. This example assumes that you parsed the token value into a variable. Make sure to update `rootdomain.com` with your domain. if (rwgToken !== undefined) { document.cookie = "_rwgToken=" + rwgToken + "; max-age=2592000; domain=rootdomain.com; path=/"; } Each time Google generates an `action_link` that you have provided through the feeds, the URL is modified to include a unique query parameter: `rwg_token`. You must store this token, and pass it back as part of the conversion event. #### **Store at Device-Level** The device-level includes the use of browser cookies, local storage, app local storage, or any other method that can persist the token for the 30 days attribution window. The token is stored locally on the user's device. So, the conversion event can't attribute properly, if the user: - Changes the device they use. - Clears the local storage or cookies. - Uses a private or incognito browser. When you use the device-level conversion tracking, you need to re-implement the conversion event across every supported device that includes mobile. #### **Store at User-Level** The user-level persists the token in your application database, through a server-side analytics system or other server-side systems. The token is stored on the server-side. So, the conversion event still attributes properly after the user logs back in. When you use user-level conversion tracking based on your system architecture, you can implement the conversion event once on your server-side and reuse it across all supported devices. > [!NOTE] > **Note:** You can decide where to store the `rwg_token` based on your requirement. ### Refresh the Token When Google refers a user to the same merchant, the existing token which is already stored, is replaced with the new token from the latest referral. After the token replacement, the 30 days attribution window of the token storage resets and any new conversions for this merchant, attribute to the latest token. Refer to [Requirements for Conversion Attribution](https://developers.google.com/actions-center/verticals/appointments/redirect/integration-steps/conversion-tracking#attribution-requirements) for more details. ## Parse and Store the Merchant Information When a user is directed to your booking page, you need to implement the logic that can find and capture the merchant details. Typically, partners add merchant metadata or `merchant_id` to their action links and use that to identify and store the merchant information. We recommend you to store the `merchant_id` or the selected identifier along with the `rwg_token`. When a user confirms a booking, you can refer to the merchant before you send the complete conversion request. Similar to the token storage, you **must** save the merchant details with the token for 30 days after the initial referral. The following example modifies the previously stored `rwg_token`. It assumes that you parsed the merchant information from metadata in the provided URL and either saved it as a `merchant_id` or matched it to an existing `merchant_id`. // Store the rwgToken and merchantId in your cookie and set the cookie // expiration date to 30 days. if (typeof rwgToken !== 'undefined') { document.cookie = "_rwgToken=" + rwgToken + "; _merchantId=" + merchantId + "; max-age=2592000;domain=rootdomain.com; path=/"; } ## Return the `rwg_token` and the `merchant_changed` Values When a user completes a booking that begins from an `action_link` referral, you need to send an HTTP POST request to the conversion endpoint. There are two endpoints: - **Production environment**: https://www.google.com/maps/conversion/collect - **Sandbox environment**: https://www.google.com/maps/conversion/debug/collect When you send a conversion event, you **must** include the stored `rwg_token` and a `merchant_changed` value of `1` or `2`. For more details on `merchant_changed`, see [Return the Merchant Change Value](https://developers.google.com/actions-center/verticals/appointments/redirect/integration-steps/conversion-tracking#return-merchant). The POST body must be a JSON encoded object in the format: { "conversion_partner_id": "", "rwg_token": "", "merchant_changed": "1|2" } { "conversion_partner_id": "XXXXXXX", "rwg_token": "AFd1xnHrJWKcjtriCyB5j3QL0bzbmLdcg1N1f5cJuSNVhteYjuOJz18Au6GIAT0tjHkw6fkUJKcarafV45b3c_gl7uT_o8HMcg==", "merchant_changed": "2" } The following example includes device-level conversion tracking with a cookie on the user's device, written in JavaScript: const partnerId = XXXXXXXXXX; const endpoint = `https://www.google.com/maps/conversion/collect`; // Retrieve the value of the rwgToken stored in the browser's cookie const match = document.cookie.match(new RegExp('(?:^| )_rwgToken=([^;]+)')); const storedRwgToken = match ? match[1] : undefined; // Send Conversion event with decoded token, verify any special characters // are sent properly. if (storedRwgToken !== undefined) { fetch(endpoint, { method: "POST", body: JSON.stringify({ conversion_partner_id: partnerId, rwg_token: decodeURIComponent(storedRwgToken), merchant_changed: merchantChanged }) }); } > [!CAUTION] > **Caution:** The only accepted `MIME Content-Type` is `text/plain`. **Don't** set any other `Content-Type` in the header, which results in a CORS error. > [!WARNING] > **Warning:** Verify that as part of conversion data user Personal Identification Information (PII) is not sent to Google. > [!NOTE] > **Note:** In production, you must not send conversion events that aren't attributed to this integration. It's best practice to check for a valid and unexpired `rwg_token` value before you send the event. ### Return the Merchant Change Value The `merchant_changed` value is used to determine if the merchant is changed from the initial redirect merchant. Change of merchants is common if your landing page is within a platform that includes other merchants. In this case, if a user is referred to your platform by Google and decides to navigate to a different merchant to complete a booking, you need to know that a conversion happened with a separate merchant. You can use a Boolean to identify the merchant change, but not the merchant details. When you decide which value to assign to the `merchant_changed`, you need to take the original merchant saved in [Parse and Store the Merchant Information](https://developers.google.com/actions-center/verticals/appointments/redirect/integration-steps/conversion-tracking#collect-merchant). Check if the merchant has changed, and assign the value as per your requirement. - **Requirement** : when a user leaves the original merchant's website and completes a purchase through your platform with a different merchant. - **Merchant change value** : `1` - **Requirement** : when the user completes a transaction through the original merchant. - **Merchant change value** : `2` > [!NOTE] > **Note:** If your booking page isn't within a platform or users are unable to navigate to a different merchant, you can hardcode the value of these requests to `2`. This is common for partners who integrate their booking pages into their merchant's website or have custom landing pages to process a booking. ## Test and Verify the Conversion Tracking The following test cases use test tokens provided in the [Test Tokens](https://developers.google.com/actions-center/verticals/appointments/redirect/integration-steps/conversion-tracking#test-tokens) section and are intended to help guide you through all of various scenarios that can result in a conversion event. This ensure that the token is stored appropriately, the `merchant_changed` value is set correctly, and the conversion event is sent when appropriate. Use the action link or booking page URLs provided in your feeds, and run each test case by appending the [Test Tokens](https://developers.google.com/actions-center/verticals/appointments/redirect/integration-steps/conversion-tracking#test-tokens) to the end of the URL. Be sure to use a private or incognito browser window -- this will clear any existing tokens associated with the current user and give you a clean slate to work with. | **Test Case** | **Test Description** | **User Flow** | **Expected Outcome** | |---|---|---|---| | 1 | A user completes a booking that did not originate on Google. | A user navigates directly to the booking page without being referred to by Google or without an existing referral. This shouldn't result in any conversion event. | **No conversion event** because the user did not previously visit the booking page or was not referred by Google. | | 2 | A user completes a booking that originated on Google. | A user finds your merchant through Google, is referred to your booking page and completes a booking. | **A conversion event would be sent** with *Token A* and *merchant changed* value of *2* because the user was referred to the booking page by Google. | | 3 | A user (originating from Google) begins the booking flow, but abandons the session before a booking is completed. **Note: Keep this session open for Test 4 and 5.** | A user is referred to your booking page but the session ends and they don't complete a booking. | **No conversion** because the user did not complete a booking but *Token B* should be stored for 30 days. | | 4 | A user returns to the booking page, without having been originating from Google, and completes a booking. **Note: The booking flow URL must not include an rwg_token.** | A user returns to the booking page after **Test #4** . *Token B* should be stored for 30 days and any conversion during those 30 days should return a conversion event. | **A conversion event would be sent** with *Token B* and *merchant changed* value of *2* because the user is returning to the booking page after previous referral from Google. | | 5 | A user completes a new booking originating from Google after **Test #4**. | If a user returns to your booking page using a Google referral after a previous Google referral, their 30-day storage window resets and a new token *Token C* replaces the old one *Token B* . All future conversions will then be attributed to *Token C*. | **A conversion event would be sent** with *Token C* and *merchant changed* value of *2* because the user completed the booking and the new token replaced the previously stored token. | **If you have a platform with the ability for users to checkout with a different merchant, test the following.** > [!IMPORTANT] > **Important:** As noted in the [Return the Merchant Change Value](https://developers.google.com/actions-center/verticals/appointments/redirect/integration-steps/conversion-tracking#return-merchant) section, you can hardcode the value of these requests to `2` if your booking pages or Action Links don't have the capability for a user to switch merchants. This is common for partners who integrate their booking pages into their merchant's website or have custom landing pages to process a booking. If you're one of these partners, you can skip the following test cases. | **Test Case** | **Test Description** | **User Flow** | **Expected Outcome** | |---|---|---|---| | 6 | A user is referred to your booking page by Google and completes a booking with a different merchant. | A user is referred to your booking page by Google, *Token A* is used, but before completing a booking they navigate to a different page and complete the booking with a merchant that differs from the original referral. | **A conversion event would be sent** because the user completed a booking that originated with a referral from Google with *Token A* and *merchant changed* value of *1* because the user completed the booking in a different merchant than the referral. | While you test, send the HTTP POST request to the conversion endpoint. There are two endpoints: - Production environment: https://www.google.com/maps/conversion/collect - Sandbox environment: https://www.google.com/maps/conversion/debug/collect ### Test Tokens To test conversion tracking, add one of the following test tokens to the end of the Action links or booking page URLs you provide in your feeds. **Token A:** rwg_token=AFd1xnHrJWKcjtriCyB5j3QL0bzbmLdcg1N1f5cJuSNVhteYjuOJz18Au6GIAT0tjHkw6fkUJKcarafV45b3c_gl7uT_o8HMcg%3D%3D **Token B:** rwg_token=AE37R_gte8WCEaytMalsIr9agWQRLuN8199RsVhU2WoRKRvcZ0eBTD8cFvnfUZh-GY0IvY-zjS3W9KWAmy3WDiWXbVvQRZyzMQ%3D%3D **Token C:** rwg_token=AE37R_jmAP-UgWNApkxwdlX5M2z1UBGuUzHZ63YWmRWeTjRJKxfSD1mzJ4joLnB11MHrBULuisjP-9I64LnBJDXyCc_CIJSCPg%3D%3D When you send the successful conversion events, you can see them aggregated in the Action Center under the conversion tracking dashboard. > [!NOTE] > **Note:** Conversions can take up to an hour to appear in the dashboard. ![conversion-tracking-dashboard](https://developers.google.com/static/actions-center/images/conversion-tracking-dashboard.png) ### Requirements for Conversion Attribution Google's required standard for conversion attribution is a 30 days attribution window for any interaction with a place action link, at any store. This attribution window means that Google can 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 days attribution 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 days attribution window. Merchant change value = 1. Additionally, Google expects to send conversion events from any device, a user can access through a place action link. These devices include: - 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, it's expected that you provide cross-device attribution. For more information, see [Store at User-Level](https://developers.google.com/actions-center/verticals/appointments/redirect/integration-steps/conversion-tracking#user-level). In this case, a user who follows an action link from the desktop and then completes the transaction on mobile with the same user account, must trigger a conversion event. If the token is stored exclusively at the device-level, such as in browser cookies, it's not expected that you provide cross-device attribution. In this case, each device can have a separate token persisted, if the user follows an action link on that device, and each device can follow the attribution rules separately. > [!NOTE] > **Note:** This attribution framework can be different from your analytics system attributes conversions. This system is designed to operate independently of any conversion tracking you do in your systems, and need not affect your internal analytics.