How to read call logs

Who this is for: anyone investigating a specific call — yours, a buyer’s complaint, or a publisher asking why they were not paid. What you’ll need: an approximate time, and any one of: caller ID, tracking number, campaign, or buyer. Time: a few minutes per call once you know the sequence.

Call Logs hold the evidence behind each call: whether it reached Moja, which campaign it matched, which number received it, how it routed, whether it connected, and whether it met the configured revenue or payout rule.

This article is the process. For what an individual field means, see the Call log column dictionary.

Call Logs or RTB Logs?

Use	To answer
Call Logs	Did an actual phone call happen, and what became of it
RTB Logs	Did a bid request happen, who bid, who rejected, and was a callable destination returned

RTB activity with no matching call log means the request never became a phone call. A call log means the call reached Moja and can be traced from the call side.

Step 1 — Narrow the time range first

Before opening any individual call, filter Call Logs to the period the issue happened in. If someone reported a specific call, get the approximate time, caller ID, tracking number, campaign, or buyer from them.

Select a range of no more than 31 days for each Call Log request or export. For longer history, review or export consecutive windows. Older links with longer ranges open their final 31 days with a notice; check the displayed dates. Direct over-limit requests receive an explanatory error. The shared Reporting picker also applies its selected window to summaries and charts, but this is not a blanket limit on every reporting API. Older call history is not deleted. QAI reporting uses the picker under QAI Analysis → Reports.

A tight time range is the difference between reading one call and guessing through unrelated traffic.

Expected result: a result set small enough to scan.

Step 2 — Find the row

1. Search by tracking number, caller ID, campaign, publisher or source, or buyer — whichever you have.

2. Open the call row or the call detail view.

Expected result: one row that matches the reported time and caller.

Note

No row at all is itself a finding. It means the call did not reach Moja, or the tracking number and source are misassigned — not that the routing failed. Check the number’s campaign attachment before looking anywhere else.

Step 3 — Read the chain in order

Read the row in the order the call actually travelled. The first field that is empty or wrong is where the investigation stops.

1. Did it arrive on the number you expect? Check the tracking number and the direction/source.

2. Was it attributed correctly? Check the campaign and the publisher/source.

3. What routing was used? Check the routing plan against the campaign’s intended setup.

4. Was a destination chosen? Check the selected buyer and selected target. Empty here means no eligible destination — stop and check target status, hours and timezone, caps, filters, and duplicate rules.

5. Did it connect, and for how long? Check call status, duration, and disconnect reason. Failed, canceled, timed-out, busy and unanswered outbound attempts do not count as connected in reporting or connected-call caps merely because a destination is attached. A successful zero-duration connection is not automatically a failure.

6. Did it qualify? Check conversion status against revenue and payout.

Expected result: you can name the exact step where reality diverged from your configuration.

Step 4 — Open Call Life for the sequence

The row tells you the result; Call Life tells you the order things happened in. Open the call and select Call Life for the event timeline — routing decisions, pre-bridge and preconverted checks, and inbound RTB activity, with a side panel for individual event detail.

Use it whenever the outcome disagrees with the configuration you believe you have.

Step 5 — Cross-check the other surfaces

• If RTB was involved, compare the call against the RTB request and RTB logs using the RTB request ID.
• If the destination is SIP, review the SIP response or disconnect detail — see What are SIP responses?.
• If a voice agent ran, open Voice Agent Conversations on the call detail for the summary and full transcript.

Compare calls using Voice Agent metadata

Select a date range in Reporting, then group Summary View by Metadata tag or Metadata category. Apply Voice Agent Metadata Tag or Voice Agent Metadata Category in Advanced Filters to narrow Call Summary and Call Logs using exact-match, exclusion, contains, or does-not-contain rules. Open a summary metric to inspect its calls with the classification retained.

In Call Logs, enable Voice Agent Metadata Tag and Voice Agent Metadata Category in Columns when needed; they are hidden by default. These describe the linked agent’s current saved metadata, not caller collection tags. Editing an agent’s labels may reclassify earlier linked calls. Multiple groups may contain the same call; do not sum overlapping groups as distinct calls.

Untagged identifies linked agents without labels; Uncategorized identifies labels without a category. Calls without a linked agent do not gain metadata from Voice Agent duration alone. Exclusion filters may retain unlinked calls, so they do not necessarily identify other tagged agents. Metadata reporting here applies to Call Summary and Call Logs, not every chart, QAI view, or VA Pulse.

Common patterns

What you see	What it usually means	What to do next
Call log exists, no buyer or target selected	No eligible route was available	Check routing plan, target status, hours and timezone, caps, filters, and duplicate rules
Buyer and target selected, call failed	Destination or connection failure	Check disconnect reason, the target’s phone or SIP endpoint, buyer availability, and the SIP response
Call connected, revenue is zero	Qualification or payout rule not met	Check the duration threshold, the buyer payout condition, buyer rejection, and revenue configuration
RTB logs exist, no call log	The RTB request never became a call	Review the RTB response, reject reasons, the bid winner, and whether a callable destination was returned
Call under the wrong campaign	Tracking number or source assignment is wrong	Check the number’s campaign attachment
Failures only at certain times	Hours or timezone mismatch	Compare campaign timezone against target and buyer hours
Second call from the same caller earns nothing	Duplicate rules are treating it as a repeat	Configuring sticky caller and duplicate call routing

Worked example: “the call did not connect”

1. Filter Call Logs to the reported time range.

2. Search by tracking number or caller ID.

3. Confirm the campaign and publisher/source are the ones you expect.

4. Check whether a buyer and target were selected at all. If not, the call never got as far as dialling — the problem is eligibility, not delivery.

5. If a target was selected, read status, duration, and disconnect reason. Now the problem is delivery.

6. If RTB was involved, compare the RTB request and response.

7. If SIP is involved, read the SIP response code.

That split — eligibility versus delivery — decides who you talk to next. Eligibility problems are yours to fix in configuration. Delivery problems usually belong to the buyer.

What to send support

• Call UID, or an example call
• Approximate date and time, with timezone if relevant
• Campaign name
• Tracking number or caller ID
• The buyer or target you expected
• What happened, against what you expected
• RTB request ID or SIP response code, if applicable

These trace the exact call in one round trip instead of three.

Related

• Call log column dictionary — what each field means
• Why are my calls not connecting?
• Why am I getting calls but no revenue?
• Why am I seeing RTB logs but no call logs?
• What are SIP responses?
• Create your first campaign

Last reviewed: August 2026.