Skip to content

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.

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.

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.

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.

  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.

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.

  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

Section titled “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.

  • 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.
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”

Section titled “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.

  • Call log ID, 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.

Last reviewed: August 2026.