Scam tracker and caller ID app marketing strategy: a launch playbook for a contracting category

The category is contracting in India while the overall market grows. Sensor Tower's 2025 India wrap, reported by TechCrunch in January 2026, lists security apps among the declining download categories in a year when total India downloads rose to 25.5 billion. Truecaller's India downloads fell 16 percent year on year. You are launching into a shrinking pool.

That incumbent is also diversifying away from you: India's share of Truecaller's download base slid from over 70 percent to the mid-50s, and global downloads fell 5 percent.

The US has the same structural shape, and it is worth one line as contrast rather than as a plan: Robokiller, Hiya and Nomorobo compete against carrier-native products — T-Mobile Scam Shield, AT&T ActiveArmor, Verizon Call Filter — that are free and preinstalled. In both markets the carrier and OS layers are absorbing the value proposition.

Monetisation explains why incumbents tolerate this. Truecaller's revenue is roughly 65 to 70 percent advertising, with in-app subscription revenue at $39.3 million in 2025 and enterprise revenue growing 39 percent year on year in constant currency. The leader runs an ad business with a thin premium layer and a growing B2B verified-caller product attached — and that ad business is fragile: Truecaller lost roughly a third of its ad traffic from Google, its largest partner, in August 2025.

Two conversion rates that are not the same number

This is the single arithmetic error that wrecks plans in this category, so it gets its own subsection.

Monthly-active-to-paid is about 0.8 percent. Four million-plus paid subscribers against 500 million-plus monthly actives. Both figures are disclosed; the division is mine, not a published rate.

Install-to-paid is roughly 0.3 to 0.4 percent. The same 4 million-plus subscribers against a lifetime download base above one billion. That is the denominator your media plan uses, because you buy installs, not monthly actives.

The gap between them is a factor of two to three, and it runs the wrong way for anyone planning optimistically. Every volume threshold later in this post uses the install-based rate. If you see a plan that quotes 0.8 percent and then multiplies it by installs, it is understating the volume it needs by about three times.

Because it costs nothing to acquire a user. Sanchar Saathi is free, state-backed and carries the credibility of the Department of Telecommunications, and it reached 1.4 crore downloads by December 2025 with no paid media. Separately, network-level caller name presentation is rolling out to every Indian mobile number. The core caller ID feature is being nationalised.

Get the preinstall episode right, because it is widely misreported. On 28 November 2025 the DoT ordered manufacturers to preinstall Sanchar Saathi within 90 days, non-removable. Five days later, on 3 December 2025, the Ministry of Communications withdrew that requirement after a privacy backlash, citing voluntary adoption as sufficient. The app remains available and user-removable. Many articles published after the withdrawal still describe the mandate as active.

The withdrawal is not the important part. What matters is what Sanchar Saathi gives away free: fraud reporting through Chakshu, IMEI verification, stolen-device blocking, connection audit through TAFCOP, spoofed-call reporting.

Then CNAP — Calling Name Presentation. Multiple Indian outlets reported through 2026 that network-level caller name display, sourced from operator KYC databases, is rolling out to every Indian mobile user with a privacy opt-out. I have not retrieved the primary TRAI or DoT directive, so treat the dates as reported rather than confirmed and verify against trai.gov.in. The direction is not in doubt — TechCrunch named CNAP explicitly as a competitive pressure on Truecaller. It delivers verified caller identity from KYC records, at the network layer, free, with no install and no permissions.

So the wedge is what CNAP does not do:

• Scam pattern detection — CNAP gives you a registered name, not the fact that this number called 4,300 people this week.
• SMS and link phishing — smishing sits entirely outside the caller ID frame, and it is a different product on both platforms.
• Fraud reporting and recovery workflows — the twenty minutes after someone realises they have been defrauded is an unserved journey.
• Community reputation beyond KYC — a verified name attached to a bad actor is still a bad actor.
• B2B verified business caller — the part of the category that is growing rather than shrinking, and the one wedge that is not a mobile user-acquisition business at all.

Pick one. A general-purpose caller ID app in India competes with a free government utility and a telco network feature at once.

Your activation event is a permission grant, and it is the only event that matters. On Android it is being set as the default caller ID and spam app, with call log access alongside. On iOS it is the user manually enabling your call directory extension in Settings. Nothing downstream happens without it, and it is revocable.

This category differs from every other one here in one way: the value event requires an adversary to show up. In a habit tracker the user creates the value event. Here, a scam call has to arrive. Users in low-spam segments install, grant permissions, see nothing for two weeks, and uninstall an app holding their call log.

Install
  → Open
  → Phone number verification (SMS Retriever API — never READ_SMS)
  → ★ ACTIVATION: default Phone / Caller ID role granted
      ├─ READ_CALL_LOG / READ_CONTACTS consent
      └─ display-over-other-apps permission
  → First spam call correctly identified   ← the aha moment
  → First ad impression served             ← where the revenue actually is
  → First user-initiated number lookup     ← high monetisation signal
  → D7 retained with permissions intact    ← the real [retention](/blog/app-retention-benchmarks) gate
  → Paywall exposure → subscribe           ← 0.3–0.4% of installs

Two things no generic playbook will tell you. First, activation is revocable and often silently revoked: Android auto-resets permissions for unused apps, so a user who activates on day zero can be de-activated by the OS on day 14 without ever opening your app. Instrument "permission still held" as a daily metric, or your activation number will look healthy while your protected base decays underneath it.

Second, the obvious fix for the missing aha moment creates a policy problem. Scanning existing call history to show "you already received 14 spam calls this month" is good product design, and it needs call log access at the exact moment you are trying to earn trust — the permission under the tightest scrutiny on Play. The category eats its own tail here.

The iOS ladder is shorter and worse: install, open, then the user manually enables the extension in Settings › Apps › Phone › Call Blocking & Identification — outside your app, across several taps. There is no push callback telling you it happened, but you are not blind: poll CXCallDirectoryManager.getEnabledStatusForExtension(withIdentifier:) on every foreground and you get the extension's enabled state directly. That call is how you build the in-app "are you protected?" check, and it is also how you fire a reliable activation event on iOS instead of guessing.

Four things, in order: a Play permissions declaration that survives review, a Play production-access clock that has already started, an event taxonomy separating permission-granted from permission-still-held, and a decision on whether you are shipping one product or two. Get the declaration wrong and there is no campaign, because there is no app.

Google Play's SMS and Call Log permissions policy reserves those groups for apps registered as the default SMS, Phone or Assistant handler. An exception list covers apps where no alternative exists, and it explicitly names "caller ID and spam detection/blocking" and "anti-SMS phishing/smishing." The category is permitted, conditionally: you must submit a Permissions Declaration Form covering every SMS and call log use case, and Play states that failure to declare, or misleading declarations, can result in app removal or account termination.

Never use READ_SMS for OTP verification — Play directs you to the SMS Retriever API, which verifies automatically with no permission at all, and requesting READ_SMS anyway is the most common self-inflicted rejection here. One change is coming on 27 January 2027: account verification by phone call stops being a permitted READ_CALL_LOG use case. Caller ID, spam detection and spam blocking remain permitted, unchanged — the core permission your category depends on is not under threat; the adjacent ones are.

Start the Play production-access clock before you write a media plan. Personal Play Console accounts created after 13 November 2023 need 12 testers running a closed test for 14 continuous days before production access is granted, with review typically inside seven days after that. Organisation accounts are exempt. Testers who opt in for fewer than 14 days and then opt out do not count, and if a tester opts out and returns, the clock restarts. In a category where your closed test also has to prove the permission flow works across Xiaomi, Vivo and Oppo skins, budget a month for this, not a fortnight. Older guides saying 20 testers are out of date.

Do not build on the Accessibility API. Play's policy restricts it to tools whose primary purpose is assisting people with disabilities, and explicitly names antivirus, monitoring apps, automation tools, assistants, cleaners and launchers as restricted. Declaring isAccessibilityTool=true waives the disclosure requirement but requires a declaration covering disability types served, target users and a demonstration video; the stated consequence for a false claim is app suspension and developer account termination.

Android 17 makes this worse. Under Advanced Protection Mode, introduced in Beta 2 in March 2026 and reported by The Hacker News and Malwarebytes, non-accessibility apps are blocked from the API entirely, existing grants are revoked, and users cannot re-grant without disabling the mode. Plan for the irony: the users most likely to turn the mode on are exactly the security-conscious users you want most.

Instrument these events separately:

Mark the ones you will bid on as key events in Firebase, and if you run Google and Meta use a measurement partner — Firebase plus the Meta SDK gives you two incompatible definitions of the same permission event, and here that definition is the business.

It means you are processing the personal data of people who are not your users and never agreed to anything. India's Digital Personal Data Protection Rules were notified in November 2025, with substantive obligations enforceable on 14 May 2027. A caller ID app is the hardest consent problem in the Act, and no post in this category should skip it the way most do.

The problem in one sentence: when your user grants READ_CONTACTS, you receive the names and numbers of several hundred third parties who have no relationship with you, no notice from you and no way to consent. DPDP carves out no exception for that. Notice, purpose limitation, retention limits and erasure rights attach, and the data principal is the person whose number was uploaded, not the person who uploaded it. The reference case is the historic Truecaller contacts-upload issue, which is also why Apple's guidelines restrict uploading address books to servers without explicit consent — verify the current guideline text before you write anything into a listing or a declaration.

Four decisions, in decreasing order of how much they cost to retrofit:

• Do not upload raw address books. Hash or tokenise numbers on device and transmit only what your matching needs. A design that never holds a plaintext non-user number sidesteps most of the problem.
• Publish a non-user removal path that does not require installing your app. Truecaller's unlist page is the pattern; build yours before launch, not after the first complaint.
• Write the notice in English and the user's own language, with a stated purpose and retention period, and match it exactly to your Play Data Safety declaration. A mismatch between declaration and behaviour is an enforcement trigger on its own.
• Keep community reports separate from identity data. "This number was reported 4,300 times" is aggregate; "this number belongs to Rahul" is personal data about a third party. The wedge that survives CNAP is the aggregate one, which is conveniently also the one with the lighter compliance load.

This is a summary of an obligation, not legal advice — take Indian counsel on your consent architecture before launch, because the answer depends on your data flows rather than your category. And note what the enforcement date does and does not give you: time to design for this, none at all to ignore it.

Smishing is the wedge with the most headroom and the least overlap with CNAP, and it is a completely different permission and platform story from caller ID. If you pick it, most of the caller-ID mechanics above do not carry over.

On iOS, the mechanism is ILMessageFilterExtension, an app extension that iOS hands messages from unknown senders to classify as junk, promotional or transactional. The constraint that decides your architecture: the extension has no general network access. It can perform one deferred lookup, to a single HTTPS endpoint you declare in the extension's Info.plist as ILMessageFilterExtensionNetworkURL, and nothing else — no arbitrary API calls, no several endpoints, no live model phoning home. Either your classifier runs entirely on device, or your whole server-side intelligence has to fit into one request and one response to one URL. As with the call directory extension, the user enables it manually in Settings, and the same enabled-status polling discipline applies.

On Play, the mechanism is a declaration, not an API. The SMS and Call Log permitted-use list names "anti-SMS phishing/smishing" explicitly, which is what makes the product publishable — but only if your Permissions Declaration Form says so. Expect to describe the core feature, why it cannot be delivered without the permission, and in practice to supply a demonstration video. Declare smishing specifically; a declaration written for caller ID does not cover it.

The SMS Retriever distinction matters twice over, and most write-ups cover only one half. For your own OTP flow, use SMS Retriever: no permission at all, and asking for READ_SMS to do a job it already does is the most common avoidable rejection here. But SMS Retriever is useless for the smishing product itself, precisely because it only ever returns messages you sent. Scanning inbound messages from unknown senders genuinely requires the restricted permission, and that is exactly the case the permitted-use list exists for — say so plainly in the declaration rather than hoping the reviewer infers it.

Two consequences. Classify on device wherever you can, because uploading message bodies puts the content of Indian citizens' private messages into your infrastructure and back into the DPDP problem above. And treat smishing as a separate ASO and creative motion: different terms, different screenshots, different demo, and bundling both into one listing dilutes both.

Every store screenshot is a policy artefact here. Play's Deceptive Behavior policy prohibits false or misleading claims in description, title, icon and screenshots, and its own worked example is security-specific: an app claiming to be antivirus that only contains a text guide. Treat ASO creative review as compliance review.

Start with category selection. On Play, list under Communication or Tools, where Truecaller and Hiya sit — not under a security or antivirus framing, which invites the scrutiny you want to avoid. On the App Store, Utilities is the convention.

Claims that get you rejected, or approved and then enforced against later:

• Absolutes: "blocks 100 percent of scam calls," "complete protection," "detects all fraud."
• Antivirus or malware-scanning framing unless you genuinely ship scanning, or screenshots showing detection the build does not do.
• Any implication of government endorsement. Referencing DoT reporting channels is fine; implying the DoT endorses you is a Play misleading-claims risk and a legal risk in India.

Bounded claims pass and convert nearly as well: "identifies numbers reported by our community."

No verified keyword volume data exists publicly here. The lists below are informed inference — validate every term in Play Console search-terms reporting or a paid ASO tool first.

India, Play, English: caller id, spam call blocker, call blocker, who called me, unknown number, phone number search, scam alert, fraud call.

India, vernacular and transliterated: कॉलर आईडी, spam call band karo, unknown number kiska hai, नंबर किसका है.

India, the fraud wedge — lower volume, far higher intent: cyber fraud complaint, scam number check, UPI fraud, digital arrest, fraud number report, chakshu.

India, the smishing wedge: sms spam blocker, fake link checker, otp fraud, phishing sms, block spam sms.

The constraint unique to this category is that your best keywords collide with your policy exposure. Antivirus, protection, secure and "block all" in title or subtitle create substantiation risk. Prefer verbs describing what you do — identify, warn, report — over adjectives describing what you are.

Run Apple's documented four-campaign structure, and accept that your iOS product is a different product from your Android one. Budget for the manual Settings activation step in your cost-per-activation maths, not just the install.

Before the structure, a warning about the number everyone quotes. AppTweak's India Apple Ads CPI of $0.89 is an all-category median across its India panel, not a security-app figure — and it is low because the India iOS auction is thin, with iOS at roughly 4 to 6 percent of Indian devices, not because the channel is efficient. Cost per tap is similarly panel-dependent: AppTweak's 2025 dataset puts the global median at $0.92 and the US at $1.91, while Adapty's separate panel of a million-plus ad groups puts the US at $1.58. Publish and plan on the range, never on one number.

The historic iOS model is the CallKit call directory extension: your app ships an offline database of numbers to the OS, sorted ascending, with no network access at call time, so it cannot look anything up live. For a decade you could only identify numbers already downloaded to the device.

Live Caller ID Lookup in iOS 18.2 changed that. Apple shipped a homomorphic-encryption lookup API: the device encrypts the incoming number locally, sends it to your server, gets an encrypted response, and decrypts on-device — you never see the plaintext number. Advice written before 2025 saying iOS caller ID cannot work properly is out of date. But this is server infrastructure answering homomorphic-encrypted queries, not a port, and activation is still a manual Settings toggle. Two products, two campaign plans, two cost models.

Apple's own documented structure:

Add every keyword from the first three campaigns into Discovery as exact-match negatives, so Discovery only spends on genuinely new terms.

The competitor campaign is where the volume is, and where the legal question is. "Truecaller" is the highest-volume relevant term in India, and Apple Ads policy permits bidding on competitor keywords. Whether that use is actionable under Indian trademark law is unsettled — the Delhi High Court line of cases has held that keyword use of a registered mark can amount to infringement or passing off, and Apple's ad policy does not settle Indian law. Take advice before you build a campaign around a named incumbent, and if you run it, expect a high cost per tap and a low install rate anyway, because most of that traffic wants Truecaller. Cap it and judge it on activation rate, not install cost.

Two separate Apple products get merged constantly, so keep them apart:

• The four-campaign manual structure above uses Manage Bids, a maximum cost per tap you set, and exact-match discipline. It has no conversion-volume gate of any kind.
• Maximize Conversions, launched 25 February 2026 for search results, is automated bidding to a target CPA with a daily budget. Apple's documented guidance is to budget for at least five conversions a day, run at least two weeks before judging, and note that Search Match is mandatory on its automatic ad group. It is not available for pre-order campaigns, and the target CPA is a weekly average goal rather than a per-query ceiling.

Search Match being mandatory on Maximize Conversions conflicts with the exact-match discipline of the four-campaign structure, and Apple has published nothing reconciling them. Run the classic manual structure, or run a Maximize Conversions campaign alongside it, but do not try to run both inside one campaign.

Consider Apple Ads Basic if your iOS product is thin. Basic prices on cost per install rather than cost per tap, has no keyword management, runs on search results only, and is capped at $10,000 per app per month. For an India-primary caller ID app where iOS is a few percent of the addressable base and nobody will read a keyword report twice a week, Basic is often the right answer and Advanced is a hobby. Advanced earns its keep only when the competitor campaign, custom product pages or the negative-keyword flow are doing real work.

AppTweak's 2025 dataset — about 3,500 apps, 50,000 campaigns, $1 billion in spend across 38 countries — gives the reference points: global median CPI $1.80, US $4.06, India $0.89, India conversion rate 48 percent. No Apple Ads benchmark exists for security apps specifically.

Android is where the product actually works and where almost all your India volume lives. Start with App campaigns for Installs on target CPI, respect the documented budget floors, and change nothing before 100 conversions have registered. Once you have cleared 100 conversions, move to target CPA on permission-granted. That is the sequence: start on target CPI, then move to target CPA on permission-granted after 100 conversions. Do not open on target CPA because its budget floor is lower.

Google's documented minimums are the numbers practitioners most often get wrong:

Google's exact wording on learning: making changes to your in-flight campaign before the first 100 conversions have registered may disrupt learning. That is a conversion count, not a time window. Google also documents that you should not select more than one action for target CPA, and that iOS bids typically run about 1.5 times Android.

Do the arithmetic first. At a ₹20 (about $0.23) India Android target CPI, the target-CPI floor is ₹1,000 a day (about $11). At a ₹35 (about $0.40) target CPA on permission-granted, the floor is ₹350 a day (about $4). The lower floor is the reward for having cleared the first stage, not a shortcut past it.

One piece of Android good news: the Privacy Sandbox for Android was cancelled in October 2025, so GAID persists and deterministic user-level attribution continues. Plan iOS around aggregate measurement, Android around deterministic measurement.

On burst installs. Tactics are covered in the launch playbook, but two facts stay in every version of this advice. Apple added a named clause, 5.6.3 "Discovery Fraud," in the February 2026 Guidelines revision, sitting under the Developer Code of Conduct where the stated remedy is termination of your Developer Program account rather than app rejection. Apple's sentence, in full: "Manipulating any element of the App Store customer experience, such as charts, search, reviews or referrals to your app, erodes customer trust and is not permitted." The Section 3 preamble reaches your agency too — "or engage with third-party services to do so on your behalf." Google separately states it filters incentivised installs out of its ranking systems, escalating to removal from top charts and then from the store, so the burst can be silently zeroed while you still pay for it. And Google's enforcement does not stop at one app: "any related Google Play developer accounts will also be permanently suspended." One burst is a company-level risk. In a category whose entire pitch is trustworthiness, this is a strange hill to die on.

Meta is where you build the case for the permission, which is a job search ads cannot do. Run App Installs optimisation to start, move to App Event Optimisation on permission-granted once you clear roughly 50 events per ad set per week, and use creative to pre-frame the permission request before the user meets the operating system prompt.

That second job is category-specific. Elsewhere, creative sells the outcome. Here it also has to explain why an app needs your call log before Android shows a system dialog asking for it. Users who see the rationale in the ad plausibly grant at higher rates than users who meet the prompt cold — a testable hypothesis, not a measured fact, and worth an experiment cell in month one.

Note the sourcing problem honestly: Meta's Business Help Center is blocked to crawlers, so every threshold in circulation comes from trade press rather than Meta. The commonly cited figure is roughly 50 optimisation events per ad set per rolling seven days to exit learning, with budget changes, creative swaps and audience changes all resetting it. A useful counterpoint: raising budget purely to escape the "learning limited" label typically yields only 5 to 10 percent improvement, while consolidating into fewer, larger ad sets is the structural fix.

What Meta does document: App Installs is the recommended default, App Event Optimisation requires App Events enabled, and Meta discourages Link Click Optimisation if you have the SDK installed. Value Optimisation, which is the goal you would eventually want for an ad-monetised app, is documented as available on a limited basis to partners and advertisers rather than to everyone — check your account before you plan around it. On iOS you get up to eight conversion events ranked by priority, only the highest-priority event in a session is reported, and reordering pauses affected ad sets for a 72-hour cooldown. Set the ranking once — permission-granted high, subscribe at the top — then leave it alone.

The creative difference in one line: your ads must demonstrate a threat without manufacturing fear, and that boundary is also the boundary between an approved ad and a rejected one.

Advertising is 65 to 70 percent of the category leader's revenue, so an ad plan is not an appendix to this playbook — it is the playbook. If your model is subscription-first, the arithmetic in the next section will tell you it does not work, and it will be right.

Start with the payback calculation, because it decides everything else. Maximum viable CPI equals ARPDAU multiplied by the cumulative daily-active-user days you expect per install over your payback horizon. Model a caller ID curve at D1 30 to 40 percent and D30 8 to 12 percent — above generic benchmarks on D1 because permission-gated onboarding self-selects, below them on D30 because revocation and OS-native substitution create a decay mode other categories lack — and you get roughly five to six cumulative DAU-days per install by day 30.

At a ₹20 CPI and 5.5 DAU-days, paying back by D30 on advertising alone needs an ARPDAU of about ₹3.6, roughly $0.041. At four ad impressions per daily active user, that implies an effective CPM near ₹910, about $10. No tier-one source publishes India eCPM for a utility or communication audience, and nobody in this market is getting $10 CPMs on non-rewarded inventory. That is the point, and it is the most useful thing in this section: ad monetisation in India does not pay back a bought install by D30. It pays back over quarters, and only if retention holds. It is the arithmetic behind an incumbent needing 350 million Indian monthly actives, and the reason your plan needs organic and referral supply alongside paid. Run your own version with measured impressions per DAU and measured eCPM before month two — it is four numbers, and it decides whether the business exists.

Formats, in a category where the wrong format is actively corrosive. You are selling protection from unwanted interruption. An unwanted interruption is therefore not a neutral monetisation choice:

Brand safety is a monetisation setting, not a legal chore. A scam-protection app that serves a loan ad or a gambling ad has undone its own positioning in one impression. Use your mediation platform's ad-content filters to block financial-services, lending, gambling and dating categories, accept the eCPM hit, and treat the difference as a marketing cost rather than lost revenue.

Mediation and measurement, in build order. Ship one network and a mediation layer at launch, add a second and third demand source once the DAU base is stable, and turn on impression-level ad revenue reporting from day one — it is the difference between knowing what a cohort is worth and guessing. Pipe that revenue into your measurement partner, which is where it becomes usable in bidding: Google App Campaigns can take a target ROAS against it, and Meta's Value Optimisation can where your account is eligible.

One trap. Firebase auto-collects ad_impression from AdMob, and it fires several times per daily active user, so it clears every platform volume threshold trivially. That makes it a superb diagnostic and a poor bid target: optimising to it buys users who see ads, which is not the same as users who are worth something. Bid on permission-granted for activation and on ad revenue value for money, and use ad_impression counts to sanity-check both.

Possibly, and if you do, this post does not apply and neither does mobile user acquisition. Enterprise is the fastest-growing part of Truecaller's business at 39 percent year on year in constant currency, and it is growing in a category that is otherwise contracting. But verified business caller is an outbound enterprise sales motion, not an app-install motion, and handing a reader a consumer UA playbook for it would be the same error this series criticises elsewhere.

Here is the honest shape of it.

What you sell. A verified identity, a brand name and logo, and — the part CNAP does not deliver — a stated call reason, delivery analytics and answer-rate reporting on the enterprise's outbound calls. CNAP commoditises the identity half at the network layer, so the durable product is the branding, the reason-for-call and the measurement, not the name.

Who buys. Compliance and customer-operations teams inside telecom operators, banks, insurers and NBFCs, and logistics and delivery firms whose riders' calls go unanswered. The buying committee is typically a business owner in collections or customer service, an IT or platform team, and a compliance sign-off. None of them are in your app.

How it is priced, and how long it takes. Per seat, per verified number, or per call or message delivered — annual contracts, invoiced, through procurement, not in-app purchase. Three to nine months from first meeting to signature is the working assumption for a regulated Indian buyer, longer with a security review. Plan a pipeline, not a campaign calendar.

How you generate demand, in rough order of what works for a first-time entrant: outbound to a built list of compliance and customer-ops leaders at named accounts, with a compliance-led rather than feature-led message; compliance content pegged to TRAI and DoT developments, which is what those buyers actually read; BFSI technology and customer-experience events, where one conversation beats a month of impressions; channel partnerships with the CPaaS and telecom messaging aggregators already selling into those teams; and a small LinkedIn paid budget used to warm named accounts rather than to generate volume.

What you measure. Cost per qualified lead, meetings booked, pipeline coverage, sales-cycle length, annual contract value and net revenue retention. Set the cost-per-qualified-lead target by working backwards: if total sales and marketing cost to acquire should stay inside one year of contract value, your lead-to-close rate back-solves the lead cost. No published India benchmark exists, and any page offering one is guessing.

What the app is for. A demo, a credibility artefact, and the consumer-side network that makes your enterprise identity worth displaying. It is a cost centre in this plan, not a channel. If you are building the enterprise business, stop reading this post at the budget table and go write a sales plan.

Pick the deepest event that clears its platform threshold at your intended budget, and never skip a rung. The ladder here is install → permission granted → first identification shown → ad revenue → subscribe.

Optimise to permission-granted, and do not plan to graduate from it. That is not a phasing recommendation, it is a permanent one, and the arithmetic says so.

Work backwards with the install-based conversion rate, not the monthly-active one. Meta needs roughly 50 optimisation events per ad set per rolling week. At an install-to-paid rate of 0.3 to 0.4 percent, subscription optimisation needs 12,500 to 16,000 installs per week, per ad set. At a ₹20 CPI, that is ₹2.5 to ₹3.2 lakh per week for one subscription-optimised ad set — call it ₹2.9 lakh a week, about ₹12.5 lakh a month, to feed a single ad set, before you have run a second ad set, a second platform or a creative test. No budget in the table later in this post supports that, and a plan that pretends subscription optimisation arrives "in quarter three" is describing a business that does not exist. Design one that never needs it.

Permission-granted is the opposite case. It converts at perhaps half to two-thirds of installs, so 50 events a week needs 75 to 100 installs per week per ad set — reachable in the validation tier on day one. The rung below it, first identification shown, is not in your control at all, because it requires a scam call to arrive, so it belongs in your KPI ladder and never in your bid strategy.

Ad revenue is the exception that changes the shape. Once impression-level revenue is flowing into your measurement partner, a value or ROAS bid strategy is fed by impressions rather than by rare conversions, and impressions are abundant. That is the only realistic path to a revenue-optimised campaign in this category, and it is another reason the ad plan is not optional.

Four mechanisms make optimising too deep too early fail: statistical starvation, where the campaign never exits learning and CPA inflates; sparse-signal overfitting, which is why Google says not to select more than one action; reset cascades, where each fix restarts learning; and iOS signal decay, which most playbooks miss.

That last one matters here. Under AdAttributionKit you get three conversion windows from first launch: days 0 to 2, days 3 to 7, days 8 to 35. Fine conversion values exist only in the first postback and only at crowd-anonymity Tier 2 or 3; windows two and three are always coarse; and at Tier 0, where a low-volume new app lives, they produce no postback at all. Encode your most important signal in the first 48 hours or you will not see it. Permission-granted almost always happens on day zero, so it fits the fine-value window naturally. Subscription does not. That is a structural argument for optimising to activation rather than revenue on iOS, independent of volume. Validate on Android, then port to iOS.

Show the moment, not the threat. The strongest format is a screen recording of an incoming call where your warning banner appears — the product demo is the ad. Fear-led creative buys installs and destroys retention, because the fear promise is redeemed only when a scam actually arrives, and for most users it does not.

Five things to test:

1. Specificity beats scale. "₹22,495 crore lost to fraud last year" is abstract, and that figure comes from an aggregator citing I4C, MHA and RBI second-hand — go to the primary sources before publishing it, and keep it in your blog rather than your creative. "This number called 4,300 people last week" is concrete, provable and yours.
2. Pre-frame the permission. Creative explaining why call log access is needed does UX work in an ad slot. Give it a dedicated cell.
3. Borrow authority carefully. Referencing DoT, Sanchar Saathi or I4C reporting channels lends credibility; implying endorsement is a Play misleading-claims risk and an Indian legal risk.
4. Regional language is a segment, not a translation. Vendor data suggests vernacular creative delivers 40 to 60 percent better click-through in Tier-2 and Tier-3 India, and that Tier-3 CPI runs 25 to 50 percent of Tier-1 levels — but the same source makes that discount conditional, and the condition is the operationally useful half: it holds only if the product is genuinely vernacular and the APK is under 25MB. A 60MB English-first build in a Tier-3 campaign does not get the discount; it gets a worse install rate. Treat both figures as directional and measure your own. Low-production testimonial creative also outperforms studio work in trust categories.
5. Name the fraud type, not the category. "Digital arrest," "UPI refund scam," "KYC expiry SMS" are recognised threats in India with their own search demand. "Spam protection" is not.

Avoid fake virus or threat alerts, which carry malware and deceptive-behavior exposure on Play; countdown-pressure paywalls, corrosive in a trust category; and any claim of completeness. The line between demonstrating a threat and fear-mongering is enforced by both Meta and Google. A recording of a real scam call with the number redacted, captioned factually, sits on the safe side. A simulated "YOUR PHONE IS INFECTED" alert does not, and it will get the ad rejected and may get the app flagged.

No tier-one measurement company publishes CPI benchmarks for security or caller ID apps in India. What exists is a vendor-reported India utility CPI of ₹10 to ₹25 (about $0.11 to $0.28) on Android, and AppTweak's $0.89 Apple Ads India figure — which, again, is an all-category median from a thin iOS auction rather than a category anchor. Build from those two anchors plus your own measured grant rate, and treat month one as measurement rather than growth.

The highest-variance term is the permission-grant rate, and it varies enormously by manufacturer skin — Xiaomi, Vivo and Oppo flows differ materially from stock Android. Measure it before committing budget. Cost per activated user is CPI divided by grant rate: at ₹10 to ₹25 CPI and a 50 to 65 percent grant rate, roughly ₹18 to ₹50 (about $0.20 to $0.57). A derivation, not a benchmark.

Creative production comes out of the monthly figure, not on top of it. A plan that budgets media and then discovers it has no assets is the most common way the validation tier gets wasted.

Why the top tier is capped, when other posts in this series scale past it. ₹35 lakh a month at a ₹20 CPI buys about 175,000 installs a month, roughly 5,800 a day, in a category the first paragraph of this post describes as contracting. That is already an aggressive share of the daily addressable pool for a non-incumbent wedge product. Beyond it you are not buying more installs, you are buying the same installs at a higher price — and the way you will find out is CPI drifting up week over week while install volume stays flat. Run that check monthly: if your CPI has risen more than about 20 percent while volume has not moved, you have found the ceiling of the auction, and the next rupee belongs in retention, referral or the enterprise motion rather than in media.

The KPI ladder, in priority order:

1. Permission grant rate by OEM and by creative. Everything else is downstream.
2. Permission retention at D7 and D30 — the share of granting users still holding it. This decides the business.
3. ARPDAU, blended across ad and subscription revenue. This is the headline revenue metric in a category that is 65 to 70 percent advertising, and it belongs above every install metric.
4. Impressions per daily active user and eCPM by format, which are the two levers underneath ARPDAU.
5. Time to first identification, and cost per activated user rather than cost per install.
6. Manual lookups per active user per week — the best behavioural monetisation predictor.
7. Subscription rate, watched but never optimised to.

For retention, the only broad dataset is Adjust's undated page: combined D1 26 percent, D7 13 percent, D30 7 percent, with Utility at 21 percent D1. Expect D1 above that, because permission-gated onboarding self-selects committed users, and D30 below it, because revocation and OS-native substitution create a decay mode other verticals lack. Model D1 at 30 to 40 percent and D30 at 8 to 12 percent, then replace both with measured values.

Five failure modes account for most dead launches in this category, and three of them end the app rather than merely damaging a campaign. Two are policy failures with account-level consequences, one is a measurement failure that hides itself, and one is not your fault at all. Read them as a pre-mortem before you write the plan.

Your permissions declaration is rejected, or accepted and later enforced against. Cost: total. Play states that failure to declare or misleading declarations can result in app removal or account termination, and termination cascades to related developer accounts. Declare every use case explicitly — including smishing separately from caller ID — and never describe one your build does not implement.

You built on the Accessibility API. Cost: the product stops working for your best users. Advanced Protection Mode in Android 17 revokes existing grants automatically and blocks re-granting. This is not a policy risk to argue with; it is a technical block on the device. Rebuild on the default-handler role model.

You uploaded raw contact books. Cost: a DPDP problem you cannot engineer your way out of after the fact, plus an App Store guideline exposure. The people whose numbers you hold are not your users and never consented. Hash on device, publish a non-user removal path, and make your Data Safety declaration match the code.

You planned a subscription business. Cost: the whole plan. At 0.3 to 0.4 percent install-to-paid, subscription optimisation needs 12,500 to 16,000 installs per week per ad set, and the revenue at Indian price points — Truecaller Premium is ₹84 a month excluding GST, about $0.95 — does not fund the media that would buy them. The category leader is 65 to 70 percent advertising for a reason.

You measured activation once and never again. Cost: a slow, invisible decay of your protected base while the dashboard shows healthy activation.

And the one that is not your fault: the category. If the incumbent is shrinking with 350 million monthly actives and a decade of data, a generic entrant shrinks faster. The failure mode is not a bad campaign — it is a good campaign pointed at a value proposition the government is about to provide free.