Installing the CleverTap SDK takes an afternoon. Integrating CleverTap properly takes two to five weeks, and the difference is entirely in decisions made before anyone writes code: how you resolve identity, how you name events, what you send as a user property versus an event property, and how you handle the anonymous-to-known merge. Get those wrong and everything downstream still works — dashboards render, campaigns send — which is exactly why teams don't discover the problem until month six, when segments don't match reality and nobody trusts the retention board.
We've run these integrations and rescued a fair number of them. This is the decision list we work through before touching an SDK.
1. How will you resolve identity?
This is the decision that costs the most to change later.
CleverTap tracks a user by an Identity — typically your internal user ID, an email, or a phone number — and merges anonymous activity into that profile when the user logs in. The trap: whatever you pick becomes the join key for your entire profile database, and changing it later means either living with split profiles or running a migration.
The rule we apply: use your immutable internal user ID as Identity, and send email and phone as profile properties, not as identity. Emails change. Phone numbers get recycled. Users sign up with Google and later add a password. If your Identity is an email, every one of those events forks a profile.
The exception is a product where the phone number genuinely is the
account — most Indian consumer apps, for instance. Even then, make sure
your login flow calls onUserLogin with a consistent, normalised value
(E.164 format, no spaces, no leading zeros) or you'll create three
profiles for the same person.
What happens to anonymous activity before login?
CleverTap assigns an anonymous device profile and merges it into the
known profile when you call onUserLogin. Two things to verify in
staging: that pre-login events (app opens, product views, add-to-cart)
actually appear on the merged profile afterwards, and that logging out
and logging in as a different user creates a clean profile rather than
inheriting the first user's history. That second case is the one QA
almost always misses, and it's how you end up sending user A's
abandoned-cart push to user B.
2. What's your event taxonomy?
Before the first pushEvent call, write the event list down in a
spreadsheet and get marketing to sign it. Not because it's bureaucratic —
because CleverTap has practical limits on distinct event names and
properties, and because an event namespace that grows organically becomes
unusable within a year.
A taxonomy that survives:
- Past-tense, title-case, human-readable names.
Product Viewed,Checkout Started,Subscription Renewed. Notprod_view_v2, notevt_checkout_1. - One event per user action, differentiated by properties. Send
Product Viewedwith{category, price, source}, notProduct Viewed ElectronicsandProduct Viewed Apparel. - A property naming convention with types locked.
priceis always a number, never sometimes the string"499". CleverTap infers type on first sight and mixed types silently break numeric segmentation. - A hard cap you agree to. Most products need 25–60 events. If your list is at 200, you're logging telemetry, not engagement events — that belongs in your analytics warehouse.
User property or event property?
User properties describe who someone is and persist: plan tier, city,
lifetime order count, signup date. Event properties describe what
happened: the SKU, the amount, the payment method. The common mistake is
storing something that changes as a user property and never updating it —
a plan property set at signup and never refreshed means every upgrade
campaign targets the wrong cohort.
3. Which SDKs, and who owns them?
A typical integration spans the iOS SDK, the Android SDK, the web SDK,
and server-side events via the HTTP API. They do not behave identically,
and this is where drift begins: the mobile team ships Checkout Started
with a total property, web ships it with amount, and six months later
nobody can build a cross-platform funnel.
Two safeguards worth the effort: a shared, version-controlled event schema that all three platforms import from, and a single owner for the taxonomy who reviews every new event before it merges. On teams building AI-assisted, this matters more — generated code will happily invent a plausible-looking property name every time.
When should events go server-side instead?
Anything that must be reliable: payments, subscription state changes, refunds, fulfilment. Client-side events get lost to network failures, ad blockers, and users force-quitting the app. The rule we use — if a campaign or a revenue report depends on it, fire it from the server. Client SDKs handle engagement surface events; the server handles truth.
4. Have you set up push properly on both platforms?
The two-week delay in most CleverTap projects is push notification plumbing, not SDK integration.
On Android, that's FCM credentials, notification channels (mandatory
since Android 8, and a channel you create badly can't be renamed later),
and the runtime POST_NOTIFICATIONS permission on Android 13+. Handling
the permission prompt well — asking in context after a user has seen
value, not on first launch — routinely doubles opt-in rates.
On iOS, it's APNs auth keys (use a .p8 key, not certificates that
expire annually), the notification service extension for rich media, and
provisional authorisation if you want to deliver quietly before asking.
Budget a real week for this and test on physical devices; simulators lie
about push.
5. Do you have a QA plan that isn't "check the dashboard"?
Events showing up in CleverTap's live view proves the pipe works. It does not prove the data is right. The QA pass that catches real problems:
- Walk every core user journey on each platform and diff the fired events against the agreed taxonomy — names, properties, and types.
- Verify anonymous → login merge preserves pre-login events.
- Verify logout → login as a different user does not leak history.
- Check that every numeric property is arriving as a number.
- Confirm timezone handling on date properties; a user's
signup_datein the wrong timezone quietly shifts your day-one retention cohort. - Send one test campaign to each segment you plan to actually use.
6. What's your migration path if you're coming from another tool?
Migrating from Braze, MoEngage, WebEngage, OneSignal, or Iterable is mostly a data-modelling exercise, not a technical one. The historical event data usually can't be moved cleanly, which means you either accept a hard cutover with no history or you run both tools in parallel for 60–90 days while cohorts rebuild.
Parallel running is the right call for anything with lifecycle campaigns longer than 30 days. It costs you two subscriptions for a quarter and saves you from discovering that your win-back campaign has no one to send to. Map old event names to new ones explicitly during this window rather than carrying legacy names across — a migration is the only cheap chance you'll get to fix a bad taxonomy.
7. Who owns it after go-live?
The integration is not the project. The project is a marketing team that can build a segment without filing a ticket. Budget for dashboard setup, a written runbook covering how to add a new event, and a training session with whoever will actually run campaigns.
The failure mode here is quiet: the integration ships, the engineer who built it moves on, and eight months later the team is running the same three campaigns because nobody knows how to add an event. A 30-day post-launch optimisation window — where the team ships real campaigns with engineering support still available — is what converts an integration into a capability.
How long does a CleverTap integration actually take?
| Scope | Typical timeline | | --- | --- | | Single platform, basic events, push | 1–2 weeks | | iOS + Android + web, full taxonomy, server events | 3–5 weeks | | Migration from another CEP, parallel run | 6–10 weeks | | Add journeys, dashboards, team enablement | +1–2 weeks |
Most of that is decision-making and QA, not code.
If you want this done without discovering the identity mistake in month six, we do this as an official CleverTap integration partner — including audits of existing setups where the data has already drifted. Book a call and we'll tell you which of the seven decisions above is currently costing you.