Response mapping

This article shows how to configure response mapping, which is how Datahubb turns a buyer's reply into an outcome. Without it, a buyer that says yes in an unusual way looks like a rejection, and a bid never gets read as a price.

Response mapping is set per delivery step: once on the post, and once on each ping step.

Two modes

Simple covers the common case. You name the field that says accepted, the field that carries a rejection reason, and the field that carries the price. If the buyer answers with a flat, predictable body, this is all you need.

Advanced opens a rule builder. Use it when the reply needs real logic: an accept that depends on two fields, a duplicate that has to be told apart from a rejection, or a price that lives in a different place depending on the answer.

Switch between them with the Simple and Advanced tabs on the Response Mapping card. Moving from Simple to Advanced converts your existing settings into rules, so nothing is lost.

Prerequisites

• A buyer with a delivery method that reads a reply, which means Direct Post, Ping/Post, or One-to-One
• A real sample of that buyer's response, ideally one accept and one reject

Build the mapping

1. Go to Campaigns, open the campaign, and open the Buyers tab.
2. Open the buyer and find the Response Mapping card for the step you are configuring.
3. Switch to Advanced.
4. Open the sample response panel and paste a real reply from that buyer. Everything below can then be checked against it live.
5. Start from a template if one fits, such as HTTP 2xx only, then adjust.
6. Add each outcome you need with the Add outcome buttons, and set the rules that identify it.
7. Set the price mapping on the step if the buyer returns a bid.
8. Save, then run Test Integration and confirm the outcome and price are read correctly.

Outcomes

An outcome is a named result plus the rules that recognise it. Outcomes are checked in order, and the first one that matches wins, so put the most specific first.

Each outcome can also extract a rejection reason and a price from the reply, so the reason that reaches your Rejection Reasons page is the buyer's own wording rather than a raw body.

Writing rules

A rule reads a value out of the reply and compares it. Rules combine with AND and OR, and groups can nest, which is how you express "accepted when status is ok and score is above 50, or when the legacy flag is 1".

Three kinds of path are available:

When you have pasted a sample, the path box suggests the paths that sample actually contains, so you pick real fields instead of guessing.

Seventeen operators are available, including equals, contains, between, in a list, matches a pattern, exists, and is empty.

Check it against the sample

With a sample pasted, each outcome shows a live tick or cross saying whether it matches that sample, plus a plain-English sentence of what the rule says. Paste an accept, confirm the accepted outcome ticks, then paste a reject and confirm the rejected one does.

This is the fastest way to catch the classic mistake: two outcomes that both match, where the wrong one is ordered first.

Price

A price mapping on the step tries each path you give it in order and takes the first one that produces a value. That handles a buyer that puts the bid in one place on a good answer and somewhere else on a partial one.

On a multi-step ping, each step has its own price mapping. A step that returns no price leaves the previous step's price standing, so an earlier bid is not lost by a later qualification step that returns nothing.

Expected result

Test Integration shows the outcome you expect for an accepting reply and for a rejecting one, the rejection reason reads as the buyer's own words, and any bid appears as a price rather than zero.

Troubleshooting

• Every reply reads as rejected. No outcome matched, so nothing said the lead was accepted. Paste a real accept into the sample panel and see which outcome ticks.
• The wrong outcome wins. Two outcomes both match. Reorder them so the specific one runs first, or tighten its rules.
• The price is always zero. The price path does not point at where the bid actually is. Check it against the sample.
• A rejection reason shows as raw text. No outcome is extracting a reason. Add a reason extraction to the rejected outcome, and the cause becomes readable on the lead and on Rejection Reasons.
• Duplicates are counted as rejections. Add a duplicate outcome above the rejected one, matching whatever the buyer says for a duplicate.
• A rule on a response header does nothing. Rules read the body, the HTTP code, and the raw text. Match on one of those instead.