Read the Response Time card on a lead

This article shows you how to read the Response Time card on a lead, so you can explain why a supplier saw a slow response and where that time went.

The card splits every timed request into three parts: Datahubb's own processing, integration checks, and waiting on buyers.

Prerequisites

• An Admin role. The card is shown to admins only.
• A lead that arrived through a ping, a post or a direct post, or that was redistributed by an admin.

Open the card

1. Open Leads from the sidebar.
2. Click the lead to open its detail drawer.
3. Scroll to the Response Time card near the bottom, after the ingest logs.

Expected result: you see one row per timed request, each with a total and a colored bar.

Read the card

The card has two sections:

• Supplier response (measured on our server) lists the PING, POST and DIRECT POST requests a supplier was waiting on. A ping/post lead usually shows two.
• Redistribution (no source waiting) lists admin redistributes.

Each row shows the request type, its start time in your timezone, the total in milliseconds, and one bar split into three colors. Hover a segment to see its time.

The three parts always add up to the total. Under each bar, a breakdown names what each part contained: the stages for Processing, the providers for Integrations, and the buyers called, in the order they were called. Parts with no time are hidden.

Processing stages

A stage that did nothing is not named. If an integration check made no provider call for this lead, its time counts as Processing, not Integrations.

A ping skips the credit and phone and email stages. A redistribute runs only set up, phone and email, credit, choose buyers and send to buyers, and runs the checks only when Re-run integration checks is on.

How buyer wait is counted

• Pings in the same round go out together, so a round costs the time of its slowest ping.
• Posts and later steps run one after another, so their times are added.
• A buyer that times out, is retried, or has a retry delay counts for the full time, delays included.

Integration time is measured from the start to the end of the check, not by adding up each provider. TrustedForm and Jornaya run side by side, so adding them would count the same time twice.

Queued time on a redistribute

A redistribute that waited in a queue before it started shows +N ms queued. That wait is shown separately and is never part of the total.

Took N ms on the ingest log

Each ingest log's Response Sent step also shows Took N ms for admins, the same total as the card.

When there is no card

• The lead was added by CSV import, which skips ingest.
• The lead arrived before response timing was added.
• The lead arrived through the store-only or test ingest.
• You are not an admin.

Troubleshooting

• The supplier reports a longer time than the card. The card measures from when Datahubb started work. Network travel, server queueing and an http to https redirect happen before that. Ask the supplier to call the https:// address directly.
• Only the latest post shows. A lead keeps one post log, so a second post replaces the first post's timing.
• Integrations shows 0 but a check is enabled. The check made no provider call for this lead, so its time is under Processing.
• Buyers takes most of the time. A slow buyer, a timeout, or retries with a delay. Open that buyer's ping or post log on the same lead, and consider a lower timeout or fewer retries on that buyer.
• A redistribute total looks high. It includes every buyer tried in that run. Nobody was waiting on it, so it is not supplier-facing latency.

Timing is saved after the response has gone back to the supplier, so measuring never slows a response or fails a lead. If part of the timing cannot be worked out, it is left empty.