Testing Repurchase Nudge DMs
Testing Repurchase Nudge DMs
Section titled “Testing Repurchase Nudge DMs”Three ways to test DMs, depending on what you’re verifying.
1. test-nudge — Send yourself a DM based on your own history
Section titled “1. test-nudge — Send yourself a DM based on your own history”Finds the best repurchase candidate from your purchase history in Neo4j and sends a real push notification immediately. Good for verifying the full pipeline works end-to-end for a specific user.
curl -s -X POST "https://stage-consumer-graph-worker.us-east-1.stage-services.fetchrewards.com/api/v1/users/YOUR_USER_ID/test-nudge" | python3 -m json.toolWhat it does: Neo4j query -> CCS enrich -> eligibility check -> episode creation -> push notification. All live, all real.
When to use: Testing that a specific user’s pipeline works. Debugging why a user isn’t getting DMs. Verifying device registration.
Requires: User has purchase history in Neo4j and a registered device token.
See the testing-repurchase-nudge skill for the full E2E workflow including seeding test data.
2. sample-dms — Preview real DMs from the last scheduler run
Section titled “2. sample-dms — Preview real DMs from the last scheduler run”Replays selected candidates from the last daily scheduler run, delivering other users’ product recommendations to your device. Good for previewing what real DMs look like across the population before lifting the experiment gate.
curl -s -X POST "https://stage-consumer-graph-worker.us-east-1.stage-services.fetchrewards.com/scheduler/sample-dms?user_id=YOUR_USER_ID&n=3" | python3 -m json.toolWhat it does: Reads cached candidates from the last run, clones them with your user ID, sends real push notifications immediately.
When to use: QA review of DM copy and product cards across a variety of real recommendations. Verifying template variants (shop-only, offer-only, double-dip) look correct before widening rollout.
Requires:
- Your user ID in the
consumer_dm_sample_allowedFeature Flipper flag - A scheduler run has completed since the last deploy (daily at 3 AM UTC)
- A registered device token
Options:
n=1..10— number of samples (default 3)random=true— random selection instead of top-N by expected value
See the sample-dms skill for full endpoint docs.
3. Scheduler dry run — Verify the pipeline without sending
Section titled “3. Scheduler dry run — Verify the pipeline without sending”The scheduler has a dry_run mode (prod default) that runs the full pipeline — candidate discovery, enrichment, eligibility, selection — but logs instead of sending. Check Loki/CloudWatch for [TEST MODE] Would send notification lines.
The daily run fires at 3 AM UTC. To see what would be sent today, check the logs after the run completes.
Comparison
Section titled “Comparison”| test-nudge | sample-dms | Dry run | |
|---|---|---|---|
| Sends real push | Yes | Yes | No |
| Products | Your own history | Other users’ selections | Other users’ selections |
| Needs Neo4j data | Yes (your user) | No (uses cache) | Yes (all users) |
| Needs scheduler run | No | Yes | Is the scheduler run |
| Allow-list | None | consumer_dm_sample_allowed | N/A |
| Good for | E2E pipeline test | QA preview of real DMs | Pipeline health check |
Setup Checklist
Section titled “Setup Checklist”Before testing DMs on staging:
- Device token — Register an iOS device token for your user ID via device-registry-api (see
sending-test-notificationsskill) - Feature flags — For sample-dms: add your user ID to
consumer_dm_sample_allowedin Feature Flipper - Neo4j data — For test-nudge: seed purchase history (see
testing-repurchase-nudgeskill) or use an existing user with real data - Valkey state — If re-testing the same user on the same day, clear the processed key:
(Only needed for test-nudge and scheduler runs, not sample-dms)
Terminal window redis-cli -h stage-consumer-graph-cache.ti3eiq.ng.0001.use1.cache.amazonaws.com -p 6379 \DEL "user_processed_today:YOUR_USER_ID:$(date -u +%Y-%m-%d)"