Prelumen Analytics
Your conversions. Your server. Your data.
A customer-owned Conversion API — send conversion events from your own backend instead of handing them to platform pixels.
What this is
Customer-Owned CAPI is an optional server-side routing layer for selected conversion signals.
It is designed for teams that need campaign feedback loops while keeping the default analytics model clean. Nothing is sent to Meta or Google just because Prelumen Analytics is installed. Delivery requires an active destination, a supported event mapping, user-choice and consent eligibility, supported identifiers, and valid provider credentials.
What this is not
Customer-Owned CAPI is not a hidden ad-tech pipeline.
It is also not a full customer data platform, not a tag manager replacement, and not a promise that every campaign platform will accept every event. It is a controlled conversion-signal delivery path for specific use cases.
Prelumen Analytics keeps analytics privacy-first by default, then lets customers activate selected conversion signals when their campaign workflow requires it and the setup permits it.
Default and optional behavior
| Layer | Default behavior | Optional behavior |
|---|---|---|
| Analytics measurement | Stays in Prelumen Analytics | Can be enriched with configured modes |
| Conversion events | Stay in analytics context | Can be mapped for delivery |
| Ad-network destinations | Not active by default | Customer-owned destinations can be configured |
| Server-side delivery | No automatic delivery | Runs only when configured gates pass |
Activation flow
Conversion delivery is a gated process, not an automatic side channel.
| Step | What happens | Control point |
|---|---|---|
| 1. Capture signal | A supported conversion or custom event is recorded | Event must exist in Prelumen Analytics |
| 2. Match mapping | The event name is matched to a configured provider event | Explicit customer mapping required |
| 3. Check user choice | DNT/GPC and configured eligibility rules are evaluated | Fail closed when the signal should not be delivered |
| 4. Check consent model | Jurisdiction and customer setup determine whether delivery may proceed | Customer remains responsible for the legal setup |
| 5. Check identifiers | Only supported identifier paths are considered | Raw unsafe fields are not used |
| 6. Deduplicate | Browser/server deduplication uses the explicit event_id when present | Same token must be shared by browser and server |
| 7. Deliver | The event is sent to the customer-owned destination | Requires active credentials |
| 8. Diagnose | Delivery status and provider diagnostics are recorded | Teams can review delivery health |
Selected conversion events can stay in analytics first and be delivered outward only when explicit destination, mapping, and consent gates pass. CAPI is controlled delivery, not behavioral capture.
Customer-owned destinations
CAPI destinations are customer-owned endpoints. Prelumen Analytics does not create advertising destinations automatically and does not deliver analytics data to Meta or Google just because the tracking script is installed. A destination is only used when credentials, event mapping, user-choice checks, identifier policy, and provider requirements match.
- Meta Conversions API endpoint
- Google Enhanced Conversions or Data Manager destination
Delivery gates
Before a signal leaves Prelumen Analytics, it has to pass delivery gates. These gates keep analytics metadata, advertising identifiers, consent state, and provider delivery separate instead of treating every event property as activation data.
- Active customer destination
- Explicit event mapping
- DNT/GPC and consent eligibility
- Supported identifier fields
- Valid provider credentials
Deduplication with event_id
When the same conversion can be observed in the browser and delivered server-side, deduplication matters. Prelumen Analytics uses an explicit event_id for browser/server deduplication. The same token must be present on both sides for provider deduplication to work reliably.
Delivery diagnostics
Conversion delivery needs visible failure states. Prelumen Analytics should show whether a mapped event was eligible, where it was sent, and why delivery was skipped or rejected.
- Delivery status
- Provider
- Source event
- Deduplication event ID
- User-choice or consent reason
- Identifier status
- Attempts and errors
- Provider diagnostics
Frequently Asked Questions
- Does Prelumen Analytics send data to Meta or Google by default?
No. Delivery requires a configured customer destination, explicit event mapping, passing user-choice and consent checks, supported identifiers, and valid credentials.
- What changes when Customer-Owned CAPI is enabled?
Selected conversion events can be delivered server-side to configured customer destinations. Normal analytics reporting remains separate.
- Does server-side delivery remove consent requirements?
No. It changes the delivery path, not the customer responsibility for consent, privacy notices, DNT/GPC handling, and jurisdiction-specific rules.
- What happens when a delivery gate fails?
The event can remain in analytics, but it is not delivered to the destination. The reason should be visible in diagnostics.
- Is this a Server GTM replacement?
No. It is a narrow conversion-delivery layer for selected mapped signals, not a general tag-management or Server GTM hosting product.