Before your CRM sends data to an ad platform, approve every field

Connecting a customer relationship management system (CRM) to an advertising platform does not mean the platform should receive the whole contact record. Approve a narrow export that contains only the business event, identifiers, and values needed for a defined advertising purpose. Exclude free-text notes, attachments, sensitive categories, internal judgments, and any record that does not meet the approved eligibility rule.

Do this before choosing a connector or copying an API token. Hashing, encryption, and a secure connection protect parts of the transfer, but they do not decide whether a field belongs in the transfer.

Use the conversion-tracking change audit after the data boundary is approved and the team is ready to test a specific implementation. This guide answers the earlier question: what is allowed to leave the CRM at all?

Start with the destination decision

Write one sentence that names the purpose and the decision it will influence:

We will send [approved event] records to [platform and account]
so the platform can [measurement, optimization, or audience purpose].
We will review the connection on [date] and use the result to decide [named action].

“Improve ads” is too broad. “Send completed first appointments to the Google Ads account so we can compare campaigns by attended appointments” is specific enough to test.

Keep measurement, optimization, and audience creation separate. A platform may use similar customer information for more than one product, but your approval should not silently expand from measuring completed appointments to building a remarketing audience. Google, for example, publishes separate customer-data policies and explains that some uploaded data can also be used to generate Customer Match lists when the advertiser chooses that option. Record the exact product settings, not only the platform name.

Create the outbound data map

Copy this table for every connection. One row represents one field leaving the CRM.

The example is not a universal field list. Delete every row that does not support the stated purpose. Add a source-system path so the implementer knows whether “appointment status” means appointment.status, a pipeline-stage label, or a calculated report field.

Platform instructions change. As of this review, Google directs new enhanced-conversions-for-leads work toward its Data Manager API and documents hashed user data for matching. Microsoft documents offline-conversion objects with conversion time, goal name, click identifiers, value, and currency fields. LinkedIn documents server-side conversion events and multiple identifier choices. TikTok tells implementers to define the events, parameters, and match keys that fit the marketing objective and review them with legal and technical teams. Meta's official Business SDKs expose server-side Conversions API events and normalize and hash supported customer-information parameters through their builders.

Those are product capabilities, not instructions to send every available field. Approve the smallest useful set for the selected product and account.

Maintain a do-not-send list

Write exclusions as enforceable rules, not a vague promise to “avoid sensitive data.” Start with:

• Free-text sales, support, medical, employment, or service notes
• Call transcripts, recordings, uploaded documents, and attachments
• Passwords, authentication secrets, access tokens, security questions, or payment-card data
• Government identifiers or financial-account details
• Fields revealing sensitive traits or circumstances unless qualified legal and platform review explicitly approves a necessary use
• Internal risk labels, salesperson opinions, dispute notes, fraud suspicions, or inferred characteristics
• Records from test accounts, employees, vendors, duplicates, deleted contacts, or another business unit
• Any field that the chosen advertising product prohibits
• Any record outside the approved geography, time window, event definition, account, or customer-notice rule

TikTok's current Events API documentation explicitly says not to share sensitive data. Google separately restricts personally identifiable information in ordinary remarketing tags and data feeds while documenting specific customer-data products that accept approved user-provided data. The product path matters. Do not treat a field as permitted just because another feature on the same platform accepts it.

Put the do-not-send rules next to the mapping. Require the export or connector to fail closed when an eligibility value is missing. Sending the record and investigating later defeats the purpose of a boundary.

Separate event truth from match data

An outbound conversion usually contains two different kinds of information:

1. Event truth: what happened, when it happened, its value, and the stable source record.
2. Match data: an approved click ID or customer identifier used to connect the event to an advertising interaction.

Do not let match quality redefine the business event. A lead does not become qualified because an email matched. A sale does not become collected revenue because the platform accepted the payload. Define the stage in the CRM first, using the lead-quality scorecard and the pipeline-versus-collected-revenue guide where relevant.

Hashing also needs a precise meaning. Google, TikTok, LinkedIn, and Meta document hashing for certain customer identifiers, but not for every field. Some click identifiers and event details follow different formats. Hash only the fields the current destination specification tells you to hash, after the required normalization. A hashed email is still customer-derived matching data. Hashing does not supply consent, notice, purpose, retention, or access decisions.

Write the record eligibility rule

Turn the purpose into a filter that another person can reproduce:

Include a record only when:
- the event equals [approved business event];
- the event occurred inside [time window and time zone];
- the record belongs to [approved brand, region, and account];
- the record is not a test, employee, duplicate, deleted, or suppressed record;
- required notice, consent, or other policy conditions are satisfied;
- at least one approved match path is present; and
- every required event field passes format validation.

The correct legal condition depends on the jurisdiction, relationship, purpose, and platform terms. Have qualified counsel or a privacy professional define it when necessary. The engineering job is to make the approved rule explicit, testable, and visible in logs without exposing the customer data itself.

Reconcile every boundary with numbers

Do not jump from “CRM records selected” to “conversions reported.” Keep a count at each stage:

Use consistent denominators:

Eligibility rate = eligible records / selected records

Acceptance rate = accepted events / attempted transformed events

Reported match rate = matched events / accepted events

Suppose a CRM query selects 120 records. The documented rule excludes 15 tests or duplicates, 10 records outside the approved region and use, and 5 records missing a required event time. Ninety records are eligible, so the eligibility rate is 90 divided by 120, or 75%.

The connector attempts all 90 transformed events. The platform accepts 84 and rejects 6 for correctable format problems. The acceptance rate is 84 divided by 90, or about 93.3%. If the platform later reports 68 matches, the reported match rate is 68 divided by 84, or about 81.0%.

None of those ratios is a privacy score or proof of attribution. The 30 exclusions need reason codes. The 6 rejections need correction or a documented closeout. The 68 matches say nothing by themselves about whether the export was appropriate. If the CRM, connector, and platform disagree, use the report reconciliation worksheet before changing the boundary.

Test with synthetic or marked records first

Test both allowed and blocked paths before backfilling real history.

Use a non-production destination or platform test mode where available. Inspect the actual outbound request, connector logs, dead-letter or retry queues, cloud logs, and the destination result. A green connector status does not prove that excluded fields stayed out.

For production, retain the mapping version, code or workflow version, approval date, approver, query window, counts by stage, rejection reason totals, and destination response identifiers. Do not place raw emails or full payloads in general-purpose logs merely to make troubleshooting easier.

Control access, retention, and change

Name the people or roles allowed to:

• Change the CRM query or eligibility filter
• Add a mapped field
• View connector configuration and logs
• Rotate credentials
• Retry rejected records
• Change the destination account, conversion action, or audience
• Request deletion, suppression, or disconnection
• Approve a new advertising purpose

Set a review date and a stop procedure. Document how to revoke the credential, disable the workflow, empty retry queues, remove scheduled exports, verify that no new requests leave the system, handle previously shared data under the platform's controls and terms, and preserve only the evidence needed for the business record.

Treat every new field, destination product, account, audience use, jurisdiction, and business event as a change requiring review. A connector update that quietly exposes a newly created CRM property is a data-boundary change, even if no one edits the campaign.

Make one release decision

Approval belongs to a version. When the mapping changes, rerun the relevant boundary tests and the conversion-tracking release audit. Do not rely on the old approval because the connector name stayed the same.

A useful CRM connection is not the one that sends the most data. It is the one that sends a defined event through a narrow, documented, reproducible boundary and gives the business evidence to stop or change it safely. If you need help designing that measurement boundary and the reports that follow it, review Ocean Media's strategy and reporting service.