[null,null,["最后更新时间 (UTC):2025-07-26。"],[[["\u003cp\u003eConversion tracking for Reservations Business Link Integration involves collecting, persisting, and sending conversion data without including user PII.\u003c/p\u003e\n"],["\u003cp\u003eImplement conversion tracking at either the device level (using cookies, local storage) or the user level (server-side storage), ensuring data persistence for a 30-day attribution window.\u003c/p\u003e\n"],["\u003cp\u003eCollect the \u003ccode\u003erwg_token\u003c/code\u003e from the landing page URL parameter, persist it for 30 days, and send it as part of a conversion event to the designated Google endpoint upon transaction completion.\u003c/p\u003e\n"],["\u003cp\u003eGoogle's attribution window requires sending conversion events for any order placed within 30 days of interacting with a place link, regardless of the channel or store used.\u003c/p\u003e\n"],["\u003cp\u003eConversion events should be sent from all surfaces (web, mobile apps) and, if using user-level tracking, provide cross-device attribution.\u003c/p\u003e\n"]]],["Conversion tracking for the Reservations Business Link Integration involves three steps: collecting the `rwg_token` from the landing page, persisting it for 30 days, and sending a conversion event upon checkout. The `rwg_token` is stored either at the device level (using cookies or local storage) or at the user level (server-side). The token must be stored without edits, and if an existing token is present, it should be replaced, resetting the 30-day window. When a transaction occurs, send a POST request to Google's conversion endpoint with the partner ID and `rwg_token`. Avoid sending user PII.\n"],null,["# Conversion Tracking\n\n| **Objective:** Implement conversion tracking for Reservations Business Link Integration.\n| **Warning:** Please ensure that as part of conversion data, user Personal Identification Information (PII) is not sent to Google.\n\nImplementation\n--------------\n\n### Summary\n\n\nThere are three pieces to a conversion tracking implementation:\n\n1. [Collecting the `rwg_token`](#collecting) from the landing page / app entry point.\n2. [Persisting the `rwg_token`](#persisting) for the appropriate attribution window\n3. [Sending a conversion event](#sending) at checkout\n\n\nThis conversion tracking implementation does not require you to use\nGoogle Analytics or any other 3rd party javascript.\n| **Key Point:** There are two different levels at which you can implement conversion tracking, **device level** and **user level**. Both are supported during this integration, and you can choose based on your product architecture.\n\n\nBefore beginning work on your conversion tracking implementation, you should decide\nif you're going to track conversions at the device level or user level:\n\n- 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).\n- 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.\n\n### Collecting the `rwg_token`\n\n\nEach time Google surfaces an `action_link` you have provided through\nthe Feeds, that url will be modified to include a unique query\nparameter: `rwg_token`. The `rwg_token`\nvalue is an encoded string which contains some metadata about the\nlink the user clicked. You will store this token, and pass it back as\npart of the conversion event.\n\n\nOn each landing page / app entry point you must parse the value set\nfor the `rwg_token` query parameter and store it. Requirements for\nstoring this parameter are described in the step, [Persisting the\n`rwg_token`](#persisting).\n\n\nAn example for how this token can be parsed for device level tracking through\nthe browser is included below. Alternatively, you could collect this token on the\nserver side when responding to the request: \n\n```javascript\n\u003cscript\u003e\n var query = location.search.substring(1);\n var params = query.split('&');\n var rwgToken = undefined;\n for (var i = 0; i \u003c params.length; ++i) {\n var pair = params[i].split('=');\n if (pair[0] == 'rwg_token') {\n rwgToken = decodeURIComponent(pair[1]);\n break;\n }\n }\n\u003c/script\u003e\n```\n\n### Persisting the `rwg_token`\n\n| **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](#requirements) below.\n\n\nYou will be required to persist the `rwg_token` URL parameter, which\nwill be appended to all action links provided by you, for a total\nduration of 30 days. The value of the `rwg_token` should be\nstored and returned without any edits.\nIf there is an existing token persisted from a previous visit, the\nold token should be replaced, and the 30 day window for storage\nshould be reset.\n\n\nWhen persisting the token, you may either store the token at the\ndevice level or at the user level:\n\n- 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.\n- The **user level** includes persisting it in your application database, through a server-side analytics system or other server-side systems.\n\n\nBelow is an example of device level conversion tracking,\nstoring this token in a web browser via a 1st\nparty cookie. This example assumes you have parsed the token value\ninto a variable as in the example above. To use this example,\nyou will need to update \"rootdomain\" to your domain. \n\n```javascript\n\u003cscript\u003e\n if (typeof rwg_token !== 'undefined') {\n document.cookie =\n \"_rwg_token=\" + rwg_token + \";max-age=2592000;domain=rootdomain.com;path=/\";\n }\n\u003c/script\u003e\n```\n\n\nWhen using user level conversion tracking the `rwg_token` should\nbe stored on the server and associated with the user.\n\n### Sending Conversion Data\n\n\nWhen a user completes a transaction which is attributable to a\nGoogle Place Action link, you must send an HTTP POST request to the\nconversion endpoint. There are two endpoints, one for the production\nenvironment and one for the sandbox environment.\n\n- Production: `https://www.google.com/maps/conversion/collect`\n- Sandbox: `https://www.google.com/maps/conversion/debug/collect`\n\n\nThe post body should be a json encoded object in the format: \n\n```scdoc\n{\n 'conversion_partner_id': partnerId,\n 'rwg_token': \u003crwg_token_val\u003e\n}\n```\n\n\nIn both the sandbox and production environments you will be required to\nprovide a valid `rwg_token` when sending a conversion event.\nFor testing purposes in the sandbox environment you may use the following\ntest token. \n\n```\nAJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==\n```\n| **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.\n\n\nA full example of device level conversion tracking (using a cookie on\nthe user's device) in javascript of how to make this post request is\nincluded below: \n\n```javascript\nconst partnerId = XXXXXXXXXX;\nconst endpoint = `https://www.google.com/maps/conversion/collect`;\n\nconst rwgTokenCookie = document.cookie\n .split('; ')\n .find(row =\u003e row.startsWith('_rwg_token='));\n\nif (typeof rwgTokenCookie !== 'undefined') {\n const rwgTokenVal = rwgTokenCookie.split('=')[1];\n fetch(endpoint, {\n method: \"POST\",\n body: JSON.stringify({\n conversion_partner_id: partnerId,\n rwg_token: rwgTokenVal\n })\n });\n}\n```\n\n\nWhen using user level conversion tracking, you should retrieve the\ntoken which is associated with the user (regardless of the surface\nthey are on) from your server side storage mechanism and send the\ntoken using the same production or sandbox endpoints.\n| **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.\n\nConversion Attribution Requirements\n-----------------------------------\n\n\nGoogle's required standard for conversion attribution is a 30-day\nattribution window for any interaction with a place link, at any\nstore.\n| **Note:** This attribution framework may be different from how your analytics system attributes conversions. This system is designed to operate independently of any conversion tracking you are doing in your systems, and should not affect your internal analytics.\n\n\nThis attribution window means that we would expect a conversion\nevent to be sent in any of the following scenarios:\n\n- A user follows a place action link and places an order in the same session\n- A user follows a place action link and then returns from a different channel within the 30 day window to place an order.\n- 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.\n\n\nAdditionally, we expect conversion events to be sent from all\nsurfaces a user can land into from a place action link. Including:\n\n- Desktop or mobile web applications\n- Mobile apps, either through an app deep link or a registered app-intent for your domain\n\n\nIf the token is stored at the user level\n(see [persisting the token](#persisting)), it is expected\nthat you provide cross-device attribution. That is, a user who\nfollows an action link from the desktop and then completes the\ntransaction on mobile (using the same user account), should trigger\na conversion event.\n\n\nIf the token is stored exclusively at the device level, such as in\nbrowser cookies, it is not expected that you provide cross-device\nattribution. In this case, each device would have a separate token\npersisted if the user had followed an action link on that device, and\neach device would follow the attribution rules separately."]]