OneSignal onboarding and data definition checklist

The checklist starts from the first campaign. Requests to build ten campaigns during onboarding are common and mostly never finish. Pick one or two backbone campaigns, then write down in reverse which segments they need to run, and which events and properties have to arrive for those segments to stand. Written in that order, what engineering receives is not a request to send all the data but a list of event names.

OneSignal groups several devices and channel subscriptions under one user, so what to call that user is the first thing to agree on. Decide whether to use the member number or to issue a separate identifier, and confirm that the value is identical in the app, on the web, and in the backend. In the same field, record how records gathered before login attach to the account afterwards, what distinguishes one person on several devices from several people on one device, and how subscriptions are handled on logout and account deletion. Email address and phone number are identifiers and subscription targets at once, so decide which value is sent at which point.

The sheet has six fields: name, when it fires, properties and types, sample value, who sends it, and verification status. Write the name as the string engineering will put in the code. When the description in the sheet and the actual key differ, send conditions end up quietly empty. Write the firing point against the server, not the screen. Whether "purchase complete" means the moment the payment window closed or the moment the authorization response arrived changes how the journey runs. Attach a type and a unit to every property. An amount arriving as a string will not match an amount condition. The sender field records whether the app, the web, or the server sends it. The verification field records the date the value was confirmed to have actually arrived in a test.

Do not ask for push permission the moment the app first opens. A refusal is hard to reverse, so ask on a screen where the reason for the notification is already clear. Record which screen, which wording, and when a user who declined is asked again. Each channel needs different things in place: mobile push needs store certificates and keys, web push needs the site domain and the display trigger, and email needs permission to set DNS on the sending domain. For deep links, write down where a tapped message lands on a device with the app installed and on one without it.

Mark internal accounts and test devices so they drop out of real campaign audiences, and decide whether development and production are separate apps or separated by a property inside one app. Mobile push is billed on subscription records active in the last thirty days, so test devices count toward that number. Confirm on a device rather than in preview. What a substitution variable shows when empty, where a link goes, and whether a sent event actually arrives and lands in a segment all get checked in the same pass.

The handover is finished when a marketer can duplicate a built campaign, change only the segment and the trigger, and send the next one. Until then, what has to remain is the filled-in data definition sheet, the channel setup record, a campaign that has passed a live send, and the ownership of permissions and accounts. Keep the account in the customer's name and record the date access was revoked when an owner changes. When an event missing from the sheet turns out to be needed later, fill in the same fields and put it on the development schedule. The sheet stays in use after onboarding ends, so it stays on the customer's side in an editable form.