Outreach analytics goes wrong in one of two ways: too few numbers to act on, or one blended number that cannot be acted on at all. What is counted here is deliberately plain — how many went out, how many arrived, how many replied, how many became meetings — with the timing view that actually changes what you do next.
Rolled up per day, per workspace, per channel:
| EmailSent, opened, replied | 3 counts |
|---|---|
| SMSSent, delivered, replied | 3 counts |
| WhatsAppSent, delivered, replied | 3 counts |
| VoiceCalls made | 1 count |
| MeetingsBooked | The one that matters |
Delivery is counted separately from sending on the channels where the two genuinely differ — which is the difference between 'we sent 400' and '400 arrived'.
Replies are bucketed by hour across the whole day, with the peaks surfaced. This is the report most likely to change something: for most Indian B2B audiences, response is concentrated in a few hours, and moving a send by two hours is a bigger lever than rewriting a subject line.
It also has to be read against the send window — if you only ever send between 9:30am and 6:30pm, the buckets outside those hours are quiet because you were, not because your audience was.
Per-lead rather than per-campaign: a point total built from what each lead actually did, across every channel. A reply is worth fifteen times a send; an unsubscribe costs fifty. The full table is published, which is unusual and deliberate — a score you cannot audit is a score you cannot argue with.
Analytics are workspace-scoped and isolated at the database level. Data access is logged, which is a DPDP requirement rather than a feature — but it is also the thing that makes “isolated” a checkable claim rather than an assurance.
The details are in the privacy policy and the DPDP compliance page.