Data requirements for the first campaign
The CRM shows customers and purchase events. Yet a request to “send a repurchase reminder to customers who bought about a month ago” gets stuck at audience selection. It is unclear which account each buyer belongs to, whether canceled orders count as purchases and whether the customer may receive the message now.
Start by writing the conditions of one campaign and checking whether the data that determines those conditions connects to the same customer, rather than collecting more fields. Separating events, current attributes, user identifiers, device/subscription identifiers and receiving states exposes gaps. OneSignal similarly distinguishes a User from a Subscription representing a channel contact point.[1][2]
If the data is ready but execution is still blocked, check feature availability and configuration permissions. This article diagnoses data readiness first and separately examines OneSignal's product conditions later. Unless stated otherwise, field names and the repurchase scenario are illustrative design examples.
Similar names do not mean the same data role
Put the following questions in separate design fields. Do not assume a name such as customer_id is a universal standard across tools.
| Category | Question to answer | Design example | Risk of confusion |
|---|---|---|---|
| Event | What happened, and when? | Purchase confirmed; order canceled | Treating a purchase-page view as an actual purchase |
| Current customer attribute | What is the state now? | Account active; latest valid purchase time | Selecting recipients using an outdated membership level or purchase time |
| User identifier | Which account in our service is this? | Internal membership key customer_id | Counting one person as several customers or merging different customers |
| Device/subscription identifier | Which contact point should receive it? | Browser-specific push subscription ID | Treating several contact points as the same subscription |
| Technical receiving state | Can this channel receive messages? | Push subscription state; token validity | Assuming an existing customer is automatically reachable |
| Purpose/channel-specific permission | May this message be sent to this customer? | Marketing consent and change history | Replacing marketing consent with OS notification permission |
OneSignal Tags are user-level key/value attributes, whereas Custom Events communicate actions with a time. Tag values are strings, not a store for arbitrary nested objects or arrays. Keep order history in its authoritative system and define how campaign-specific current values are calculated and updated.[3][4]
Being technically able to receive push and having grounds to send promotional messages are separate facts. OneSignal Subscription Status describes channel reachability, with different interpretations for mobile and web push. It alone does not determine compliance with Korean legal marketing-consent requirements. Campaign design should maintain purpose/channel eligibility, withdrawal state and verification time separately.[1][2]
Connect the data each campaign needs — Define events and attributes from campaign needs, then align identifiers, transmission timing and measurement tools.
What establishes the same customer's identity before and after login?
Identity linking is not a one-time registration check. The following is a web-service design example. Mobile apps must separately verify the login/logout behavior of their own SDK.
Anonymous visit. Do not link an unidentified browser to a particular member. Even when using OneSignal's automatic identifiers, do not assign one shared External ID to all anonymous visitors. Connect the internal membership key only after confirming an authenticated account. The internal key, OneSignal User identifier and Subscription ID are different values and need an explicit mapping.[1][2]
Member login. OneSignal Web SDK's login(external_id) connects the browser's current web push subscription to that user. However, switching to an existing External ID does not merge the preceding anonymous data. This differs from linking a new External ID, so do not assume login attaches all previous behavior to the member's history.[5]
Multiple devices. Link verified contact points for the same account to the same internal key, but retain each subscription ID. OneSignal Custom Aliases reference identifiers from other systems. Matching Aliases alone do not connect multiple Subscriptions; an External ID is required. Choose account keys that avoid unnecessarily exposing email addresses or phone numbers.[6]
Logout and shared devices. Web SDK's logout() detaches the current web push subscription from the previous user and moves it to an anonymous user context. It does not disconnect other devices. Separately test whether A's purchase data remains after A logs out and B logs in, and whether personalized messages scheduled for the old subscription ID remain. Logout, stopping push and deleting an account are not one operation.[5]
Account closure. Deleting a OneSignal User and deleting one Subscription have different scopes. App/web reregistration or readding email/SMS can recreate records after deletion. First confirm the authoritative membership state, then prevent pending events, retries and registration paths from reviving the closed account. Completion checks should cover subsequent synchronization as well as the delete response.[7]
First-campaign data readiness matrix: a repurchase reminder
The following is a hypothetical consumables repurchase campaign. It does not describe a real customer case or a product's built-in behavior.
Review candidates daily at 09:00 in Asia/Seoul. At selection time T, candidates are active members whose latest valid purchase in the same product group occurred at least 30 but less than 37 days ago, with one day defined as 24 hours. Exclude purchases invalidated by cancellations or refunds. Verify web push reachability and permission for this purpose, and prevent repeat sends for the same reference order. This example selects one verified web subscription per customer. Preventing duplicate customer processing and preventing simultaneous sends to several contact points are separate rules.
The campaign owner first confirms those business rules. Then connect each condition to its source, owner, transmission timing and verification evidence as below. Allowed latency is this example team's operating target, not a OneSignal SLA or universal recommendation.
| Required data | Purpose | Source and owner | Identity link | Latency/timing | Verification | Action if missing |
|---|---|---|---|---|---|---|
| Confirmed purchase event and cancellation/refund state | Select the valid reference purchase | Order ledger; order backend owner | Order ID → membership key | Target propagation within 15 minutes of change; reconcile with current source state at selection | Compare amount, product group, order state and event receipt for the same order | Exclude customers with uncertain purchase validity |
| Latest valid purchase time and product group | Evaluate the 30-to-under-37-day window | Order-ledger calculation; data owner | Membership key + product group | Complete calculation before selection; record its as-of time | Compare with the ledger's latest purchase, not a partial event sample | Hold that customer until recalculated |
| Membership key/subscription link | Avoid sending to a different person | Authentication system; web development | Membership key → External ID → web subscription | Use only after checking login/account-switch results | Verify linking and unlinking with two test accounts and two browsers | Hold conflicts; do not merge by guesswork |
| Occurrence/collection times and transmission coverage | Avoid treating delay or loss as nonpurchase | Publishing/collection logs; integration owner | Source + event ID | Record source-reconciliation time separately from the 15-minute processing target | Check time zones, missing/retried events and coverage against the ledger | Do not finalize the full audience if coverage is unknown |
| Active/closed account state | Exclude inactive or closed accounts | Membership ledger; membership backend | Membership key | Check current source state before final selection | Check status changes and recreation after synchronization | Exclude until current state is verified |
| Web push subscription state | Select a usable contact point | Subscription state; channel integration | Web subscription ID → current user | Use latest verified state at selection; reflect changes | Compare allowed, refused and detached states in tests | Exclude uncertain contact points |
| Purpose/channel consent and withdrawal | Establish permission for this message | Consent ledger; privacy/CRM owner | Membership key + purpose + channel | Check before final selection; do not send while awaiting synchronization after a known withdrawal | Reconcile current state, change time and acquisition path with the source | Prohibit sending if evidence is absent or conflicting |
| Campaign processing/sending history | Prevent repeated execution for the reference order | Campaign execution ledger; CRM operations | Campaign ID + membership key + reference order ID | Query and deduplicate before retrying or rerunning | Check the outcome of processing the same candidate again | Manually investigate uncertain processing rather than resending |
The order data's “15 minutes” is a processing-monitoring target. A state from 15 minutes ago is not permission to send now. If source state cannot be checked when finalizing candidates, delay finalization or retain only verifiable recipients. Purchase/withdrawal changes immediately before sending and Journey exceptions require separate execution controls.
Do not average readiness into one score. Passing seven of eight checks does not authorize execution if the remaining one concerns identity or sending permission. Record which conditions were trusted and which uncertainty caused which customers to be excluded, rather than merely reporting a high integration rate.
Missing data is not evidence that no purchase occurred
A repurchase campaign needs evidence of both a previous purchase and the absence of a newer valid purchase. If event transmission was interrupted, classifying missing events as “no purchase” mistakes a data failure for customer behavior.
The following checks are campaign design criteria, not a particular product feature. Separate occurrence time, when the business event happened, from collection time, when the ingestion layer received it. For example, 2026-09-26T09:00:00+09:00 and 2026-09-26T00:00:00Z represent the same instant. Collection at 00:07:00Z implies a 420-second difference. RFC 3339 provides a common timezone-aware representation. An incorrect source clock also distorts that difference, so check clock anomalies separately.[8]
Internal names such as occurred_at and received_at are illustrative and must map to the destination's actual fields. OneSignal Custom Events include timestamp and idempotency_key; adding an internal field name does not automatically give it the same semantics.[9]
Deduplicate by event ID. Retransmitting one purchase event preserves its ID, while cancellation of that order is a different event. CloudEvents likewise identifies an event by the combination of source and ID. Avoid using one order ID as the deduplication key for all purchase, cancellation and refund events.[10]
For out-of-order receipt, check whether a late historical event reverses current state. Use source versions or a current source query rather than overwriting with the last-arriving value. Reconcile missing events with orders in the ledger for that period, and check whether backfilled events were already processed.
Schema changes need more than name management. If “purchase completed” changes from payment approval to shipment completion, the campaign's 30-day calculation changes even if the event name does not. Record the owner approving semantic, type, allowed-value and publication-timing changes, along with the version and rules for handling old and new events together.
From channel setup to campaigns and handover — Connect the SDK and channels, verify key campaigns and hand over an operating setup the internal team can continue.
Check ingestion, storage and audience use separately in OneSignal
OneSignal users must add product conditions to the readiness assessment. Official documentation checked on September 26, 2026 requires a paid plan for Custom Event ingestion. Receiving events for Journeys and storing them for historical-behavior segments or user-history queries are distinct. Storage is being rolled out, so confirm availability in the actual app.[11]
Storage begins when enabled; increasing retention does not restore records from before activation. Documentation specifies a maximum retention of 90 days and storage-volume limits. For this campaign, verify whether the required purchase period is actually queryable. If the CRM lacks that history, consider deriving recipients from the order source and passing them through an existing integration. Resending historical events can trigger Journeys again and must not be treated as simple history restoration.[11][12]
Inspect API responses too. Create Custom Events can return individual-event errors with HTTP 202. Logging only the status code misses events whose users could not be resolved. Documented duplicate suppression for the same idempotency_key is best effort within a four-hour window, not complete deduplication across the full retention period.[9]
An installed SDK also does not prove that the business meaning of order confirmation or server-side refund state has been integrated. Define whether Custom Events originate from the SDK, API or integration tools, and assign deduplication responsibility when several paths send the same event.[12]
How far can analytics events be reused?
Suppose GA4 purchase events are reused. Your service must assign a consistent GA4 User-ID, while a purchase event's transaction_id identifies a transaction, not a user. Matching event names or counts do not establish a link to the CRM member.[13][14]
Trace “which order, for which account, was confirmed at what time” back to its source. Retain existing instrumentation when its semantics are correct, but verify the CRM transmission path and identity mapping separately. Comparing aggregate purchase counts in an analytics dashboard is insufficient. Test records involving cancellations, anonymous visits and account switches must also connect to the correct customer.
If readiness is incomplete, hold, narrow the audience or verify manually
You need not wait until every dataset is integrated before doing anything. However, convenience cannot justify bypassing identity conflicts or opt-outs. The following are proposed execution criteria.
| Choice | Applicable conditions | Next action |
|---|---|---|
| Hold the campaign | Identity conflict, unclear sending permission, unreflected account closure/withdrawal, or unknown source-data coverage | Assign the cause and owner; do not send until the state is verifiable |
| Narrow the audience | Only some contact points/groups have incomplete data, while every essential condition can be independently verified for the rest | Retain verified customers/channels. Optional personalization can be removed when its attributes are absent; mandatory conditions cannot |
| Limited execution after manual verification | Small audience, accurate source and an owner able to check every actual recipient's conditions and current state | Record selection rules, check time, approver and duplicate-check results. Do not approve the entire audience from a sample |
This repurchase reminder does not require copying names, phone numbers and complete order documents into the CRM. Start with the membership key, product group, reference purchase time, states and evidence references needed for the decision; do not send fields with no defined purpose. Keep original consent records and detailed history in their responsible source, passing only required decision values and references to the CRM. Define retention and access per data item.
With clear sources and owners and a small first campaign, existing queries and controlled audience extraction may suffice. A separate customer data platform or new collection tool need not come first. Conversely, when systems interpret the same account or consent state differently, resolve linking rules and operating responsibilities before adding campaigns.
The OneSignal identity and event specification kit can help convert findings into an implementation specification. This article's matrix assesses whether execution is possible now; the kit turns agreed rules into development and verification items.
Readiness for the first campaign is not the number of fields collected. It is being able to explain why each customer was included or excluded and find the source, verification time and owner of that decision. Connect and verify what that one campaign needs, then expand.
If support is needed to align system sources and implementation responsibilities, IXC's customer data integration design describes its published service scope.
