How to Migrate Google Ads Conversion Tracking Safely

Your Google Ads reports can look normal right up until an import starts being rejected. If your server-side or offline conversion pipeline includes session attributes or IP address data, the weak point is now the route those fields take, not necessarily the conversion event itself.

The safest response is a controlled handoff. Identify every affected import, move the restricted data to the Data Manager API, verify the new route without counting the same event twice, and retire the old path only after reporting and error handling are stable.

First, prove that your conversion import is affected

This is not a blanket shutdown of every Google Ads API conversion workflow. The immediate trigger is narrower: new users of session attributes or IP address data cannot send those fields through Google Ads API conversion imports. Existing implementations may continue for now, but continued acceptance should not be treated as a permanent architecture guarantee.

Start with the payload your system actually sends. A design document or old integration ticket may not reflect production behavior, especially if another team added enrichment fields later.

• Find every sender. Inventory scheduled jobs, CRM connectors, server-side services, data warehouses, tag-management servers, and vendor integrations that import conversions through the Google Ads API.
• Inspect the request definition. Check the serialized payload, mapping configuration, or schema for session attributes and IP address fields. Inspect field presence without copying raw IP addresses or user data into an audit spreadsheet.
• Map the affected scope. Record which Google Ads customers and conversion actions receive data from each sender.
• Identify the developer token. The restriction is tied to allowlisting, so two integrations serving the same advertiser may behave differently if they use different credentials.
• Search error telemetry. Look specifically for CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE rather than relying on a generic failed-jobs total.
• List downstream users. Note which reports, alerts, budget decisions, and automated bidding strategies depend on the imported conversions.

You should finish this audit with one of three classifications. If neither field is present, this particular restriction is not an immediate migration trigger. If you are building a new implementation that needs either field, design it around the Data Manager API before launch. If an existing allowlisted implementation still works, use that continuity as a migration window rather than a reason to postpone the work.

Treat the change as a data-route migration

Simply renaming or deleting fields misses the architectural change. Google is positioning the Google Ads API around campaign management and core conversion workflows while directing more complex conversion and user-data transfer toward the Data Manager API.

That means your migration plan needs to separate three responsibilities:

• Event creation: the system that decides a conversion occurred and constructs the business record.
• Data delivery: the API route that carries the conversion and any associated session or user data.
• Measurement control: the monitoring that confirms events were accepted once, reached the intended destination, and remained available to reporting and bidding.

Write a field-level migration contract before changing production code. For each field in the current payload, record its originating system, its purpose, its destination in the new route, whether it may remain in the Google Ads API request, and what should happen if the destination rejects it. Explicitly mark session attributes and IP address data so they cannot leak back into the legacy request through a shared serializer or enrichment step.

The contract also needs an event identity rule. During a staged migration, two working API clients can be more dangerous than one broken client because both may submit the same conversion. Do not assume the two routes will deduplicate an event for you. Use a non-overlapping test scope or a verified deduplication control, and make the event identifier visible in operational logs without exposing unnecessary user data.

Use a staged cutover that protects conversion continuity

A migration should change one variable at a time. If you replace the API route, revise attribution logic, rename conversion actions, and alter campaign goals in the same release, a reporting difference will be almost impossible to diagnose.

1. Capture a baseline. Record normal submitted, accepted, rejected, and retried event volumes for each affected conversion action. Include conversion values and delivery delays where those matter to your reporting.
2. Instrument the current path. Make sure every submission has a traceable status and that policy errors are separated from transient delivery failures. A single generic success rate hides the failure you need to see.
3. Build the Data Manager route. Implement the mapped destination for the complex conversion and user data, including the session attributes or IP-related data your existing workflow requires.
4. Clean the Google Ads API payload. Remove session attributes and IP address fields from that route. This can prevent the allowlisting rejection while the new transfer path is established, but it does not prove that the resulting measurement is equivalent.
5. Test a non-overlapping slice. Route a clearly defined subset through the new path. Keep the rest on the existing path so you can isolate differences without submitting the same events twice.
6. Reconcile at the event and aggregate levels. Check individual event identity and status, then compare counts, values, rejection reasons, and availability timing for comparable conversion actions and time windows.
7. Expand gradually. Increase the new route’s scope only after its error behavior is understood. Watch reporting and automated bidding inputs as closely as API health because missing conversions can distort both performance analysis and bidding decisions.
8. Retire the legacy import. Phase out the affected Google Ads API conversion import only after the Data Manager route, monitoring, replay behavior, and operational ownership have all been validated.

Define stop and rollback conditions before launch

Set the conditions that pause the cutover before you begin it. Useful signals include an unexpected rise in rejected events, missing event identifiers, duplicate submissions, a material drop in accepted conversions, or delivery delays outside the range your campaigns normally receive.

A rollback must not reintroduce restricted fields into a non-allowlisted Google Ads API request. The safer fallback is to pause expansion, keep unaffected conversion imports running, and repair the Data Manager route. Replay failed events only when your retention rules allow it and your event identity controls can prevent duplicates.

Handle the allowlisting error as a routing failure

The error CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE means the conversion import was rejected because session attributes or IP address data were included without the required allowlisting. Treat it as a deterministic policy failure, not as ordinary network instability.

Automatic retries with an unchanged payload will repeat the same mistake. Your failure handler should instead follow a specific branch:

1. Stop blind retries for the rejected payload.
2. Record the affected customer, conversion action, event identifier, credential path, and prohibited field type without logging the raw IP address or unnecessary user data.
3. Remove session attributes and IP address fields from the Google Ads API version of the request.
4. Route the affected complex data through the Data Manager API.
5. Retry the cleaned conversion only if the remaining request is valid and your event controls show it has not already been accepted.
6. Alert the integration owner if the same policy error recurs after the payload has supposedly been cleaned. That usually points to a shared serializer, enrichment service, or secondary sender still adding the fields.

This distinction matters operationally. A transient failure belongs in a delayed retry queue. A policy rejection belongs in a remediation queue because time alone will not change the result.

Validate reporting and bidding, not just API delivery

A healthy API dashboard is necessary, but it is not enough. The purpose of the pipeline is to produce trustworthy conversion signals. A request can leave your system without generating the measurement outcome your team expects.

Use four layers of validation:

• Transport health: attempted, accepted, rejected, retried, and permanently failed submissions by route.
• Event integrity: missing identifiers, duplicated identifiers, unexpected field omissions, and events sent through both routes.
• Measurement continuity: conversion counts and values by conversion action, source system, and comparable time window. Compare like with like; a changed scope can make a correct migration look wrong.
• Decision continuity: sudden changes in the conversions used for campaign reporting or automated bidding. Avoid declaring a campaign performance change while a known tracking gap is still being repaired.

Choose alert thresholds from your own baseline rather than copying a universal percentage. Conversion volume and delivery timing differ too much across businesses for one threshold to be meaningful. The important control is that a known policy rejection, duplicate, or unexplained loss cannot remain hidden inside an aggregate success metric.

Keep the migration observable after cutover. The first clean deployment does not protect you from a later code change that adds the restricted fields back to the Google Ads API payload. Add a schema-level test or outbound request check that fails before such a request reaches production.

Key takeaways

• This migration is immediately relevant when Google Ads API conversion imports include session attributes or IP address data.
• Existing access may continue, but it should be treated as time to migrate rather than proof that the current route is permanent.
• Move complex conversion and user-data transfer to the Data Manager API, and remove the restricted fields from Google Ads API requests.
• CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE is a policy and routing problem. Retrying an unchanged payload will not resolve it.
• Test with a non-overlapping event scope, reconcile individual events and aggregate results, and prevent duplicate conversion submissions.
• Judge the cutover by reporting and automated bidding continuity as well as API acceptance.

Your next action is small and decisive: open the production request definition and determine whether either restricted field is present. If the answer is yes, name the migration owner, document the current baseline, and create the Data Manager route before changing the legacy importer. That sequence gives you a controlled cutover instead of an emergency caused by rejected conversions.

References

• CrushPress.AI – Google Ads API Update: Secure Your Conversion Tracking Now