Microsoft Ads Offline Conversions, Enhanced Data and CAPI

#01Which CRM milestone should be returned?

Choose an outcome that the business can define consistently. A bulk-office enquiry, a qualified opportunity and a won order are different milestones. Returning every stage as the same conversion or giving every stage full sale value can distort bidding and reporting.

Write the qualification rule with sales operations. It might require an eligible delivery market, a genuine office-order requirement and a completed review by the responsible team. Avoid subjective labels such as good lead without a documented decision rule and owner.

Record stage time, source record, value basis, correction process and expected feedback delay. A reliable deeper outcome can be more useful than a raw form, but only if it is returned consistently enough for the advertising programme. A sophisticated goal with missing uploads is not automatically better measurement.

The Google enhanced-conversions lesson offers related first-party-data concepts. Microsoft's classic offline import, enhanced-conversion and CAPI contracts are distinct routes with their own identifiers and validation.

#02How does a traditional offline import work?

Microsoft's traditional offline route uses an offline conversion goal and records linking an eligible advertising click to a later business action. Browser UET is not required merely to create and use that classic offline goal, so absence of a UET tag association is not itself a defect.

Capture Microsoft Click ID, or MSCLKID, through the approved landing-page and CRM process where permitted. Auto-tagging can append the identifier to the landing URL, but redirects, forms or integrations can lose it. A campaign name or UTM value cannot substitute for the click identifier.

The record needs the correct goal name, actual conversion time, relevant value and currency, together with the required matching information for the route. The conversion must follow the eligible interaction and fit the current import-age and attribution-window rules. Upload time is not the business milestone time.

Use a secure approved transport. Some documentation examples describe convenient public-sheet methods; customer and CRM data should not be published to the web for an advertising exercise. Use an authorised controlled integration or approved file process with appropriate access and retention.

#03Why do time and duplicate keys matter?

Traditional offline deduplication uses the combination of click ID, goal name and conversion time. Retrying the same logical record with its original identity is different from creating a new record with the current time. The latter can produce an additional outcome rather than an idempotent retry.

Store the original milestone timestamp in the CRM or integration ledger. Keep its source zone or offset and convert according to the chosen import format. API UTC conventions and user-facing file or account conventions should not be mixed casually.

For an illustrative Berlin workflow, a qualification recorded at 14:30 CET on 8 November 2026 should remain that real milestone, not become the upload's later time. Around daylight-saving transitions, preserve an unambiguous offset or UTC source rather than relying on a local clock string alone.

Separate legitimate repeated milestones from duplicates. A second genuine bulk order can be a new conversion, while a retry of the first order is not. The integration should use business identity and the documented route's key, not a rule that discards every repeated customer or accepts every repeated row.

#04How should import results be validated?

Preview and schema success are only the first layer. Inspect row errors, accepted counts, rejected counts and later attributed reporting. A syntactically accepted identifier can still fail to correspond to an eligible attributable interaction.

Build a reconciliation ledger from source milestones to exported records, accepted records and attributed outcomes. Differences can arise from invalid formatting, time rules, missing identifiers, consent restrictions or attribution eligibility. Do not repair every gap by resubmitting with new timestamps.

Define correction handling before production. Restating a value and retracting an invalid conversion have different effects. Use the supported route and original identifiers, preserve the audit trail and verify availability rather than assuming every online or offline event can be edited identically.

#05What do enhanced conversions add?

Microsoft enhanced conversions use permitted first-party identifiers, such as supported email or phone data, within eligible goal configurations. They are not a general-purpose customer-list upload and should not receive unrelated sensitive information.

Formatting and hashing depend on the route. Microsoft's online implementation can handle some normalisation and hashing in the browser, while its offline enhanced-conversion guidance requires the specified normalisation and hashing before submission. Follow the current official field rules rather than inventing a universal spreadsheet transformation.

Hashing does not make personal data anonymous or create consent. The business still needs an approved purpose, notice, secure handling and policy compliance. Do not put raw identifiers or hashes in UTM parameters, ordinary event labels or public troubleshooting documents.

Verify the actual goal's enhanced-conversion configuration and accepted identifier requirements. A traditional goal with extra fields may not behave like an enhanced goal. Do not assume that adding a hash to an old export automatically changes its matching architecture or removes every click-ID requirement.

#06What is newly important about CAPI?

Microsoft's 28 October 2026 update announces Conversions API as generally available. Older descriptions of it as only a pilot should therefore be rechecked. General availability does not mean every partner integration, account configuration or optional feature is already implemented identically.

The current guide supports server-side event routes across relevant web, CRM, offline, point-of-sale and app contexts. For marketers, the important work is the event contract, permitted identifiers, ownership and acceptance evidence. This lesson does not require code, tokens or direct API access.

CAPI is complementary to UET rather than a universal replacement for every browser function. The guide includes client-side identity-sync dependencies for remarketing and recommends relevant browser context for measurement. Do not promise complete server-only audience functionality with no browser or consent considerations.

Consent must be explicit. Microsoft's guide documents a granted default if the server advertising-storage consent field is omitted. An implementation must carry the approved state and missing-state policy; it cannot assume the website banner automatically governs an independent server request.

#07How should CAPI deduplication and responses be reviewed?

For browser-and-server reporting of the same action, use the documented shared UET context, stable event identity and compatible event naming. Preserve the same identity on retry. Sending a fresh event ID for the same purchase can defeat the intended duplicate mechanism.

Keep event identity, click identity and transaction identity separate. A transaction identifier can support supported correction workflows, while a click ID links an interaction and an event ID identifies a particular event. Their roles should appear explicitly in the implementation acceptance sheet.

HTTP success is not complete data quality. Microsoft's guide describes validation warnings, removed invalid optional fields and partial-processing behaviour. A response can be technically successful while an important field was discarded. Inspect warning details and accepted or rejected event counts.

Do not expose access tokens or raw customer payloads in a marketing workbook. Ask the authorised implementer for redacted evidence showing consent state, stable identities, value and currency, validation results and reconciliation. The marketer can verify the contract without handling secrets.

#08How should a historical backfill be governed?

A backfill should use genuine historical milestones, their original times and the permissions and route requirements that apply. It is not an opportunity to create extra conversions for a weak reporting period. Check current submission-age and attribution windows before planning the scope, and separate technically eligible records from records the business is permitted to use.

Run a controlled sample through the approved validation process and compare it with the submission ledger. Preserve the same logical identities if records are retried. If a record was previously accepted, investigate its attribution status before sending a modified timestamp or value as though it were new.

Document why the backfill is needed, which periods and goals it affects, who approved it and how reporting will be annotated. A large late upload can change apparent historical performance and bidding inputs. The reporting owner should know about that change before presenting a trend as evidence of a campaign improvement.

#09Worked example: Ledgerline

Ledgerline receives illustrative office-order enquiries online and qualifies them later in its CRM. A draft integration sends every status update as a new sale, uses upload time as conversion time and plans to retry failures with fresh event IDs.

The team redesigns the contract before launch. Qualification and won order become distinct defined milestones, the original times are preserved and values follow the agreed basis. It chooses one supported route for each outcome and specifies how browser or server duplicates will be handled.

Walkthrough

1. Agree milestone definitions and owners with sales operations.
2. Verify permitted MSCLKID capture and secure CRM storage where applicable.
3. Create a source-to-submission ledger with original time, goal and value basis.
4. Select traditional, enhanced or CAPI requirements deliberately rather than mixing schemas.
5. Review normalisation, hashing, consent and identifier handling with the implementer.
6. Test retry identity, corrections, warnings and partial failures using fictional records.
7. Reconcile accepted records with attributed outcomes and later business value.

No real customer data is uploaded. The example demonstrates a reviewable integration design rather than claiming that server-side measurement restores every missing conversion.

#10Common mistakes

Using upload time as conversion time can corrupt identity and eligibility. Publishing CRM data through a public sheet creates unnecessary exposure. Treating a successful HTTP response as complete acceptance can hide discarded fields.

Another mistake is double hashing or applying the wrong route's formatting rules. Finally, do not use server-side delivery to bypass a denied choice or claim that a hashed identifier is no longer personal data. Measurement resilience must remain within the approved privacy design.

#11Try it yourself

Design a fictional qualification-feedback ledger with source milestone, original timestamp and zone, goal, route, permitted identifiers, value, consent state and retry identity. Include one accepted record, one schema error, one duplicate retry and one later correction.

Write the evidence an implementer must provide before production: field rules, secure transport, explicit consent, deduplication, warning handling and reconciliation. State which questions remain account-specific. Leave credentials, integration changes and uploads outside the exercise.

#12Quick quiz

1. Does a traditional offline goal require browser UET to exist?

Answer: No. Microsoft's classic offline conversion route has a separate import architecture.

2. Is upload time a safe replacement for the actual CRM milestone time?

Answer: No. Preserve the real conversion time and the route's identity rules, including on retries.

3. Does an HTTP-success response prove every CAPI field was accepted correctly?

Answer: No. Review warnings, field validation, partial results and later attribution as separate layers.

#13What should the feedback approval contain?

Approve milestone meaning, secure data handling, explicit consent, stable identities, route-specific validation and reconciliation. General availability is not a substitute for proving that the merchant's particular implementation works.

Previous: Microsoft Ads Consent: Privacy Signals and Measurement Limits · Next: Microsoft Ads Reporting: GA4, Attribution and Profit Decisions

Or return to the Microsoft Ads for Marketers track.

Related: Microsoft Ads UET: Event Contracts and Layered Tracking QA · Microsoft Ads Conversions: Goals, Revenue and Deduplication · Microsoft Ads Consent: Privacy Signals and Measurement Limits

#14Common questions

Does traditional offline tracking need browser UET? No. The classic offline conversion route has a separate goal and import architecture. Use its own validation contract rather than a browser-only checklist.

Does accepted import data guarantee attributed credit? No. Format acceptance, eligible interaction matching and business validity are separate layers. Reconcile row results and later goal reporting.

Should retries use a fresh timestamp or event ID? Not for the same logical event. Preserve the original milestone and the route-specific identity so retries do not become unintended additional conversions.