Guides written by the people who built the platform.

A tracking plan fails when it is a spreadsheet that engineering is asked to honour later. Treat it as code that ships with the feature instead. Start by naming the eight or ten events the business already reports on: the signup, the first key action, the purchase, the cancellation. Write each as an object-action pair in snake_case with the three or four properties a report will actually filter on, and check the file into the repository next to the code that fires the events.

Register the plan in the event catalogue before the first SDK call goes out. The catalogue then enforces it at the door: an event with an unknown name or a property of the wrong type is quarantined with a reason rather than silently accepted, and the live debugger shows the violation next to the payload that caused it. Because enforcement happens on ingestion, nobody has to audit the warehouse a quarter later.

Then let the plan grow with the roadmap. Every ticket that adds a screen gets a one-line entry in the plan as part of its definition of done, reviewed in the same pull request. Types generated from the catalogue keep the SDK calls honest, and the CI check fails a build that fires an unregistered event. The plan stays current because updating it is cheaper than working around it.

Caps fail for one of two reasons. Either they are set so tight that every campaign hits them and marketers learn to route around them, or they live in one team's tool and the other team's sends never count. Design them as a platform rule, not a campaign setting.

Start with a per-person ceiling across all channels, not per channel. A customer who receives two pushes, one email and a WhatsApp message on the same morning has been contacted four times, whatever the org chart says. Set the cross-channel cap first, then a tighter cap for the interruptive channels (push, SMS, WhatsApp), and leave email and in-app with more room.

Quiet hours should follow the profile's timezone, not the project's. A journey scheduled for nine in the morning in Mumbai should not arrive at half past three for a customer in London. Configure quiet hours once, in the governance module, and let every journey inherit them. A message that lands in quiet hours is held until the window opens, not dropped, and the delivery log records the hold.

Finally, give marketers the exception path in the open. Transactional messages (a one-time code, an order confirmation) use a separate endpoint that bypasses caps by design and is labelled as such in the log. When the rule has a visible exit nobody needs a hidden one, and the simulation report shows how many sends each cap suppressed before the journey goes live.

A simulation replays a journey's entry conditions, branches and waits against real event history and reports what would have happened, without sending anything. Use it as the last step before activation, the way you would run a migration against a copy of production.

Pick the window first. Thirty days of history is enough for a weekly nudge; a re-engagement journey with a fourteen-day wait needs at least twice its longest wait so that the later steps have something to process. The simulation then walks every profile that met the entry segment during the window through the canvas, honouring the same frequency caps, quiet hours and holdout the live journey would apply.

Read the report top to bottom. The entry count tells you whether the segment is the size you expected; a number ten times too large usually means an operator like did-not-do is missing a time bound. The branch counts show whether a condition ever evaluates true. The suppression counts, split by cap, quiet hours and holdout, show what governance would have removed. The message count per channel is the number your provider will bill for.

If the simulation surprises you, change the canvas and run it again. A second simulation costs nothing. A journey that has messaged the wrong ten thousand people costs a great deal more, and the blast-radius ceiling exists for the day someone skips this step.

A sender-of-record platform owns the provider accounts your messages travel through, so the migration has three separate parts: events, audiences and delivery. Move them in that order and run both platforms in parallel for one full cycle of your longest journey.

Events first. Point the SDK at Edverix alongside the incumbent, using the same event names, and let the event catalogue quarantine what does not match your tracking plan. Backfill history through the import API so that retention grids and RFM scores have something to compute from on day one. Identity resolution runs on the imported events too, so profiles arrive already stitched.

Audiences second. Most segments translate directly, because they are conditions on events and traits. The ones that do not are usually built on a computed attribute the old platform kept private; rebuild those as computed attributes on the profile so they are visible in SQL. Compare segment sizes between the two platforms before you trust them.

Delivery last. Connect your own provider accounts: the APNs key, the FCM credentials, the email provider's API key, the WhatsApp Business account. Because Edverix takes no margin on delivery, the rates are the ones you negotiated. Recreate each journey, simulate it against the backfilled history, compare the numbers with the incumbent's last report, and only then move the sends. Export the old delivery log before the contract ends; you will want it for attribution.

In India, commercial SMS is regulated by TRAI under the DLT framework, and WhatsApp business messaging runs through the WhatsApp Business Platform with approved templates. Edverix connects to your own accounts for both, so the setup is mostly registration work you do once.

For SMS, register your organisation as a principal entity on one of the DLT platforms run by the telecom operators and note the entity ID you receive. Register each sender header (the six-character ID customers see) and each message template, choosing its category: transactional, service-explicit, service-implicit or promotional. Templates are approved with variable placeholders, and the content at send time must match the approved template or the operator rejects it. Add your SMS provider's credentials to the channel settings along with the entity ID and template IDs. Personalisation fills the placeholders, and the delivery log stores the template ID used for each send.

For WhatsApp, you need a WhatsApp Business Account, a verified business and a phone number connected through a solution provider or the Cloud API. Templates are submitted for approval per category (marketing, utility, authentication) and per language. Edverix stores approved templates with their variables, and journeys pick a template rather than free text for anything outside the twenty-four-hour customer service window.

Both channels respect the same frequency caps and quiet hours as the rest of the platform. Preference and consent rules, including the customer preference (DND) registry, are enforced upstream by the operator, so keep consent as a trait on the profile and use it in the entry segment.

A retention grid has cohorts down the side, periods across the top, and in each cell the share of the cohort that came back in that period. Everything useful about it follows from reading it in three directions.

Read a row left to right to watch one cohort age. The first column is always one hundred percent; the drop into the second period is the steepest, and where the row flattens is the point at which the people still present are the ones who will stay. That flattening point is the figure a product team should quote, not the first-period number.

Read a column top to bottom to compare cohorts at the same age. If the June cohort's fourth-week cell is higher than May's, something changed for people who joined in June: an onboarding change, a campaign or a different acquisition channel. Because the grid runs on the same event store as everything else, hold a property constant (the acquisition channel, say) and rerun it to find out which.

Read the diagonals for the calendar. Cells on the same diagonal share a calendar period, so a dip that runs diagonally is a dip in the product or the market that week, not a change in cohort quality.

Two settings matter. Define the return event as the action that means the product worked, not merely an app open. And choose the period to match the natural cadence of use: daily for messaging, weekly for groceries, monthly for insurance. The stickiness figure on the overview is this grid folded into one number.