Skip to main content
TrackingConsultingFree audit
Concrete CMS → Apple Search AdsIntegration guide

Connecting Concrete CMS to Apple Search Ads

Concrete CMS is a self-hosted PHP CMS used by small organisations and agencies, typically with commerce added through an add-on rather than built in. Apple Search Ads sells App Store placement, which means it lives entirely inside Apple's privacy framework and behaves unlike every other destination here. The join between them succeeds or fails on one thing: whether no user-level click identifier reaches the Concrete CMS order before the conversion happens, because Apple Search Ads can only match a conversion it can tie back to a click it recognizes.

Get my free conversion tracking auditSee what we check

Free30 minutesNo obligation

By Ariful IslamConcrete CMS → Apple Search Ads, in short ↓

Specific to this pair

Concrete CMS and Apple Search Ads: a weak fit, stated plainly

Nothing from a Concrete CMS site can reach Apple Search Ads: it attributes App Store installs through Apple's framework, with no web upload path or click identifier. Measure app download links as outbound clicks, keep install attribution in the app, and join app and web users through a shared account ID in your own database.

Apple Search Ads sells App Store placement and reports installs and in-app events through Apple's own attribution framework. A Concrete CMS site is a website. Nothing that happens in Concrete, whether a form submission or a Community Store order, can be sent to Apple Search Ads as a conversion: there is no upload path for web events and no click identifier that ever passes through your pages.

The only real relationship is indirect. If your organization has an app, your Concrete site probably links to it from a download page or a banner. Those clicks go to the App Store, not through Apple Search Ads, and should be measured in your own web analytics as outbound clicks. Install attribution for Apple Search Ads campaigns belongs in the app, through Apple's AdServices framework and your mobile measurement partner if you use one.

The sane minimal setup is no integration from Concrete at all. If someone is asking for one, the underlying question is usually whether app users also buy or register on the website. Answer that by giving app users and Concrete users the same account ID in your own database and joining there, not by pushing Concrete records toward an ad platform built around App Store installs.

Concrete CMS → Apple Search Ads · what breaks

Why this join usually fails — Concrete CMS → Apple Search Ads

  1. 01

    No user-level click identifier never reaches Concrete CMS

    Full page caching and the add-on ecosystem both interfere. Because commerce is an add-on rather than core, where the order is created differs by which add-on is installed.

  2. 02

    Commerce as an add-on, not a core feature

    Which add-on is installed determines the entire integration surface, so nothing transfers between two Concrete sites without checking first.

  3. 03

    Expecting per-user attribution that does not exist

    Teams arrive expecting a click ID to join against and there is not one. Apple's framework is aggregate by design, with thresholds and delays, and no vendor can engineer around it.

  4. 04

    Nothing reconciles afterwards

    Apple Search Ads reports at campaign level with built-in delay and privacy thresholds. Reconciling it per user against your own records is not possible by design; compare install and post-install volumes at aggregate level over a settled window instead.

Concrete CMS → Apple Search Ads · the fix

What working looks like — Concrete CMS → Apple Search Ads

  • No user-level click identifier on every order

  • Conversions arriving in Apple Search Ads

    Results appear in Apple Search Ads reporting at campaign or keyword level, aggregated and delayed by design rather than by fault.

  • Reconciled against the source

Concrete CMS → Apple Search Ads · architecture

How Concrete CMS and Apple Search Ads actually connect

  1. 1

    Concrete CMS holds the truth

    Self-hosted means you own and can query the data directly, which makes reconciliation straightforward once the identifier is present.

  2. 2

    Apple Search Ads needs a click to match

    Apple Search Ads needs the install and post-install events reported through its supported attribution path. There is no offline conversion upload in the sense the other platforms mean it, and expecting one is the usual source of wasted effort.

  3. 3

    The identifier is the bridge

    No user-level click identifier, captured at the visit and carried into the Concrete CMS order.

  4. 4

    The event source decides reliability

    Fire server-side. Page caching means the confirmation template may not execute.

  5. 5

    Deduplication at the destination

    Deduplication is largely not your problem here, because you are not sending duplicate user-level events — Apple aggregates. What matters instead is not double-counting an install across your own MMP and Apple's reporting.

Concrete CMS → Apple Search Ads · normal or broken

Working vs. broken, side by side — Concrete CMS → Apple Search Ads

Normal, not a fault

  • No user-level click identifier present on the order

  • Sent from the order-completed event from your commerce add-on

  • Deduplicated correctly

    Deduplication is largely not your problem here, because you are not sending duplicate user-level events — Apple aggregates. What matters instead is not double-counting an install across your own MMP and Apple's reporting.

  • Reconciles with the source

Actually broken

  • No user-level click identifier missing on most records

    Full page caching and the add-on ecosystem both interfere. Because commerce is an add-on rather than core, where the order is created differs by which add-on is installed.

  • Sent from the browser

    Which add-on is installed determines the entire integration surface, so nothing transfers between two Concrete sites without checking first.

  • Counted twice, or not at all

    Teams arrive expecting a click ID to join against and there is not one. Apple's framework is aggregate by design, with thresholds and delays, and no vendor can engineer around it.

  • Nobody has reconciled it

Concrete CMS → Apple Search Ads · diagnose

Diagnostic order — Concrete CMS → Apple Search Ads

  1. 01

    Count orders carrying no user-level click identifier

  2. 02

    Follow one real conversion end to end

  3. 03

    Identify which commerce add-on is in use

    That decides where the order is created and what events exist to hook.

  4. 04

    Check whether your reporting expectations match Apple's framework

    If someone has promised per-user joins on App Store installs, that is the problem — not the implementation.

  5. 05

    Read the match rate, not the success message

    Apple Search Ads reports at campaign level with built-in delay and privacy thresholds. Reconciling it per user against your own records is not possible by design; compare install and post-install volumes at aggregate level over a settled window instead.

Concrete CMS → Apple Search Ads · prove

How it gets proven — Concrete CMS → Apple Search Ads

Source of truth

Your own database's order records, at agreed states.

  • No user-level click identifier confirmed present on a live order.
  • Aggregate install and post-install volumes reconciled over a settled window, with the framework's delay stated.
  • Order attribute confirmed populated on a purchase through a cached page.

Concrete CMS → Apple Search Ads · free audit

What we check in the free audit

  • Count orders carrying no user-level click identifier
  • Follow one real conversion end to end
  • Identify which commerce add-on is in use
  • Check whether your reporting expectations match Apple's framework
  • Read the match rate, not the success message

Checked against

Your own database's order records, at agreed states.

Get my free conversion tracking audit

Free30 minutesNo obligation

Concrete CMS → Apple Search Ads · when not to buy

When you don't need this — Concrete CMS → Apple Search Ads

  • Measure identifier coverage yourself first — pull your last hundred orders and count how many carry no user-level click identifier.
  • If your Concrete site is brochure-only with enquiries by form, treat it as a lead-gen site rather than a commerce one.
  • If you have no iOS app, this destination does not apply at all — and if you do, budget for aggregate reporting rather than the per-order joins the rest of this library describes.

Concrete CMS → Apple Search Ads · what we deliver

What gets built — Concrete CMS → Apple Search Ads

  • Identifier capture into Concrete CMS

    Capture the identifier and persist it as order attribute data through an event listener, server-side.

  • Event source: the order-completed event from your commerce add-on

    Fire server-side. Page caching means the confirmation template may not execute.

  • Dispatch to Apple Search Ads

    Attribution through Apple's own APIs, with post-install events reported through your mobile measurement partner where you use one.

  • Reversals where they exist

    Order state changes recorded by the add-on.

Written guarantee

95%+ tracking accuracy

Measured against Your own database's order records, at agreed states.. Miss it and we keep working at no cost.

Get my free conversion tracking audit

From $400 · See packages

FAQ

Concrete CMS → Apple Search Ads questions, answered

No. Apple Search Ads attributes App Store installs and in-app events through Apple's frameworks and has no route for website conversions.

More on Concrete CMS → Apple Search Ads

Free · 30 min

Get Concrete CMS and Apple Search Ads joined properly

Book the free call WhatsApp

Free30 minutesNo obligation