NudgeOn
Start with one test customer. Check the audience, shape the message, and follow the result before opening the journey to more people.
Start with your appFor operators working with a team that has installed NudgeOn and connected its app. NudgeOn is a partner beta candidate; native iOS and Android SDK 0.2.8 are published.
Your team’s console and the customer’s app work together. Confirm the connection with your developer before preparing a campaign.
In the consoleStart setup · App settings
Open the console address provided by your administrator. In Start setup, check the app name so your team is working in the intended environment. Ask the administrator for access if you cannot reach it.
The setup flow covers SDK keys, channel credentials, the first event, and a test send. Your developer handles the SDK and FCM or APNs connection; you agree on the event names and the test customer to use.
Review the app’s time zone, quiet hours, and frequency limit in App settings. Use a test device with notifications allowed, a registered push token, and the correct customer identity.
The intended app is selected, its first event is visible, and your developer has confirmed the push channel connection.
Keep provider credentials and server keys with the person responsible for the integration. Screenshots and support requests should contain only the information needed to identify the issue.
Events describe what a customer did; attributes describe their current profile. Agree on names, values and sending moments with your developer, then verify actual collection in the console.
In the consoleData → Events · Attributes · User search
Select sign_up, login, purchase_completed, product_viewed, add_to_cart or checkout_started in Events. Copy the recommended properties and JSON example for your developer. For a completed purchase, include order_id, total_amount, currency and item_count.
Attributes lists first_name, last_name, email, phone, dob, gender, home_city, country, language, timezone and created_at. Agree on values such as 1995-03-15 for birth date, KR for country, ko for language and Asia/Seoul for timezone. created_at is the signup date in your service. Check the collected dictionary and collection errors too.
Confirm country = KR in the profile and purchase_completed in recent events. Choose standard names in segment event and attribute conditions, and journey entry, conversion, branches and event waits. You can also type custom attributes such as membership_level and existing event names.
Actual events and attribute values appear for your test customer, and segment or journey conditions use the names agreed with your developer.
Presets do not collect data automatically: your app must identify the customer and send it. Existing purchase events are not renamed. Sending null removes an attribute. Profile values and push consent are managed separately. A birth date alone does not schedule an annual birthday journey.
Installations with MCP enabled can share metric definitions and aggregates with an external AI to analyze performance, funnels and retention, then prepare segment and journey drafts. Connect with your own account instead of giving the AI a NudgeOn SDK key.
In the consoleSettings → AI connections (MCP) · Segments → Segment drafts
After your operator enables MCP, register the server address shown in Settings with your AI client. Sign in to NudgeOn, complete required two-factor authentication, and choose one app and its scopes. Application names are unverified: check the callback address and client ID on the consent screen. Viewer can read; Editor and higher can allow draft writing. Customer details require administrator approval and additional user consent. The default scope excludes profile fields, but user-authored names, conditions and message content are shared and may contain personal data.
Members first create a read connection and ask an administrator to approve customer access for that connection. Reconnect with the same client registration and app, then consent to customer access. Approval alone does not expand existing tokens. Use a separate connection for each app.
Ask, for example: “Analyze signup → product view → purchase over the last 30 days with a 7-day conversion window.” Ask the AI to read metric definitions first and include timestamps, time zone, denominators and collection warnings. D1, D7 and D30 cohorts whose observation window has not ended are not zero. Purchase amounts sum collected events by currency; they are not settled or attributed revenue.
Follow the AI’s console link to review the segment name, conditions and estimated audience. Save edits, then choose Create segment to make it operational. Drafts are excluded from sending; converted drafts are locked and can be duplicated. AI can edit only journey drafts that have never been published. Activate and send from the console. If another editor changes a draft, review the latest revision before applying your edits.
If draft tools are missing, check that your role is Editor or higher and that you consented to draft editing. If a save conflicts, read the latest revision and compare changes. Disconnect from Settings → AI connections (MCP) when finished, or ask an administrator to revoke customer access.
The connected app and permissions are correct, and you reviewed the analysis period, denominators and quality warnings. Review AI-created drafts in the console before using them.
MCP is optional and disabled by default. A client that supports remote MCP and OAuth is required; compatibility has not been verified for every ChatGPT, Claude, Cursor or Codex version. Role changes and revocations apply from the next request. Queries allow at most 90 days (30-day funnel or retention entry periods) and 500 aggregate rows. Account for delayed collection and merge mirroring, current-profile country and language grouping, and the absence of significance or causality judgments.
A customer is a profile. A segment is a set of conditions that selects profiles. Start with a customer you can identify before defining a wider audience.
In the consoleUser search · Data · Segments
In User search, enter the exact customer identifier or email address. Open the profile and inspect its devices and recent events. The identifier is the value your app uses to recognize the customer.
Use the Data screen for collected attributes and collection errors, and the customer profile for recent event names. Match names and values with your developer. A rule based on an event that has not arrived cannot describe the intended audience yet.
Choose New segment and give it a name your team will recognize. Add attribute or event conditions, then use AND when every condition must match or OR when any may match. Review the estimated audience before saving.
You can explain each condition in one sentence and the preview fits the audience you intended.
The preview is an estimate at the time of the query. Device state, permission, consent, and sending rules are checked separately. Before sending, ask your integration owner to confirm that opt-outs and logout changes also reach the server; automatic SDK synchronization of these changes is not yet complete.
A test push checks one customer’s connection. A journey decides when customers enter and which message or wait step comes next.
In the consoleStart setup · Test send · Journeys
In the setup flow, send a test to the customer identity used on your test device. Watch the device and open the notification. A queued confirmation means the request entered the queue; check the actual notification as well.
Choose New journey and name it. Segment entry uses a saved segment; event entry uses the exact event name collected by the app. Event entry has no segment filter, so test it in a separate test app with a test-only event. Add a push message, write its title and body, and add a wait step if needed.
Save the draft, then choose Validate and activate. Resolve the highlighted issues and review the activation summary. Activation can send real messages. Use a controlled test segment for segment entry, or the separate test app and test-only event for event entry.
An example of the sequence, not an active campaign. Choose the event, audience, delay, and content that fit your app.
The test device received and opened the message, and the journey’s audience, entry condition, copy, and sending rules have been reviewed.
To edit an active journey, use Pause and edit. Waiting deadlines continue while paused; customers already in a journey keep the version they entered. Review the effect on those customers before resuming.
APP LAUNCH ADS · iOS & ANDROID. Target all new and existing users. No login or test pairing is required; SDK integration, consent, schedule and frequency apply on selected platforms. Display an event or promotion after the launch screen for 3–5 seconds, then move automatically to the main screen. The default is 4 seconds. No close tap is needed.
In the consoleIn-app events → Full-screen startup ad example → Campaign management
Workbench · InAppTestClient · manual close
Complete when The last test on each OS ends with native close, and the same revision passes review in campaign management. This does not test four-second auto-dismissal.
Published campaign · InAppCampaignClient · auto-dismiss
Complete when Auto-dismissal, return to main and production events match. Relaunching retains frequency/suppression limits; simply returning from Home is not a new startup test.
Install the iOS or Android in-app SDK 0.2.6 and integrate the host startup flow. Enable the server in-app features and prepare a controlled test app and device. Agree on when to skip startup ads, including initial consent, deep links and permission prompts.
Select the full-screen startup ad example or upload HTML/ZIP in the in-app workbench. NudgeOn manages HTML, CSS, JavaScript and images. Edit the full-screen design and copy, then save and validate. Display duration is an SDK setting, not an HTML timer.
Check the preview, generate a pairing code and enter it in the app test connection screen. Compare confirmation numbers, approve the device, then run on your device. Check every target OS and finish the last test with the native close button. Workbench testing reviews content; do not expect four-second automatic dismissal at this stage.
In campaign management, review the same revision’s OS-specific tests and approve the review checklist. Choose the app-launch trigger. Set target platforms, start/end dates, frequency and time zone, then save the draft and publish the saved version. For one display per Korean calendar day, use Asia/Seoul. Admins/Owners approve, publish and stop campaigns.
Publish to a controlled test app first. Terminate its process and open it again: launch screen → full-screen ad → main after about 4 seconds. Check presented, impression and automatic dismissal in production records. Returning from the background does not create another launch opportunity. Restarting the process does not reset daily or suppression limits.
Stop an active campaign before editing it. Content edits create a new revision that needs a new review for each OS. Save and republish the campaign. Once the SDK and host startup flow are integrated, content changes do not require another app update.
You have verified content on every target OS and the actual startup flow of a published test campaign. Startup ads have no native close or hide-today buttons.
If no ad is available or the default 3-second preparation deadline expires, the app proceeds to main. Check publication, dates, target OS, app-launch trigger, frequency and time zone if nothing appears. Preview/device-test history is separate from production records. Ordinary in-app close and hide behavior remains available.
Check that the campaign belongs to this app, is published, is within its schedule and includes this device’s OS. Changes require review of the same revision on each target OS and republishing.
End workbench pairing, terminate the app process, then launch from its icon. Returning from Home or recreating an Activity does not create another attempt. An opportunity skipped for initial consent, deep links or permission prompts is not inserted later in that process.
For once per Korean calendar day, select Asia/Seoul and a daily limit of 1. Limits apply per installation, not account. Restarting does not reset limits or suppression. Check whether a higher-priority campaign was selected.
noCampaign/NO_CAMPAIGN: recheck publication and frequency. timedOut/TIMED_OUT: check network and content preparation. blocked/BLOCKED: check consent and presentation host. cancelled/CANCELLED: check background or screen changes. failed/FAILED: check communication and artifact validation logs. alreadyHandled/ALREADY_HANDLED: terminate the process and relaunch.
Include KST time, app/campaign IDs, source revision, OS/SDK versions, launch method, SDK result and presentation/automatic-dismissal records. Exclude secret keys, pairing codes and device tokens.
After native Close, check delivery in the app. Temporary failures show retained records and scheduled automatic retry while the app can run. After connection recovery, use Retry transfer or relaunch to recover uploads only. Rejected credentials, permissions, expiry or other permanent errors disable Retry and explain that a new review is required. Choose Prepare new review, confirm discard, then use a new pairing code to repeat the review. Discard never counts as receipt or approval. After delivery, follow “Next: approve the review in the console”: check the same revision, OS and native-close completion, then approve. Interrupted reviews must be repeated. End test session sends remaining records before closing. Expired test credentials (30 minutes) or active runs (five minutes) can reject recovery.
SDK 0.2.6 examples show the latest run ID, revision, OS, last delivery attempt, observed receipt, and session/run expiry in KST. Receipt time is observed on the device, not a server timestamp. Context survives restart. Use Copy run ID, then Console → In-app campaigns → Review → Find by run ID; match the revision and OS before approving. Search covers this app’s latest 50 runs; perform a new review if an older run is unavailable. Selection never approves automatically. Missing old-SDK fields show Not recorded, credentials are never copied, and receipt counts remain cumulative for the session while context describes the latest run.
Sending, device delivery, and opening are separate events. Use the report and the individual message log together to understand what happened.
In the consoleDashboard · Journey report · Message logs
Open the journey report to inspect entered, waiting, and completed runs and the results of individual steps. Use the dashboard for an overview, then narrow the review to the journey you changed.
Use Message logs to review the customer, channel, time, status, and failure reason for a send. A provider accepting a message is different from the device displaying it. Delivery and open reports depend on the corresponding SDK events.
Compare a controlled test with the device: notification received, notification opened, and the corresponding result recorded. If the report is incomplete, give your developer the time, customer identifier, journey, and visible error, with private values removed.
You can distinguish a request that was queued, a provider send, an observed device receipt, and an open event.
Use evidence from your own connected app before expanding the audience. A preview on this website is a demonstration; it does not send a message or establish delivery.
Check the customer identifier and the app environment first. Ask your developer to confirm the SDK connection and event collection.
Review AND/OR groups, attribute values, event names, and time windows. Check a known customer profile against the conditions before broadening the audience.
Check the device notification permission, registered token, customer identity, and channel credentials with your developer. Then inspect the message log for its actual status.
Read the highlighted validation issues. Confirm the entry event, required message fields, and connections between steps, then save and validate again.
Open the notification on the test device. Ask your developer to check delivery and open event reporting; do not treat a missing event as proof that the user did not see the message.
Use this guide for the operating steps. Share the developer center with the person connecting your app and managing the infrastructure.
Open the developer center