Skip to main content
RedTrack is an ad tracking platform that attributes conversions back to the ad click that produced them. Connecting it lets the platform report your checkouts and approved purchases to RedTrack as they happen, so each sale lands against the campaign that generated it. The mechanism in one sentence: on every enabled event the platform calls your RedTrack postback URL with a GET, sending the data as query parameters, with no JSON body. One thing decides whether any of this works: the RedTrack click id has to arrive on the checkout link. That is covered in The tracking link, and it is where almost every “nothing arrived” ticket ends.

How to configure

1

Open Integrations > RedTrack

Go to Integrations and open the RedTrack app. The screen is titled Configure Integration with RedTrack.
2

Generate the postback URL in RedTrack

In your RedTrack account, create a postback for the offer or campaign you are tracking and copy the URL it generates. That URL is what you paste on the next step.
3

Paste it under Postback URL

In the Postback URL field, paste the URL you copied. This is a template. See The postback URL and its macros for what you can put in it.
4

Choose the SUM Field

Under SUM Parameter (SUM = total of the operation), pick the SUM Field. It decides which amount is reported in the sum parameter. See The SUM parameter.
5

Enable the events and save

Under Events to be mapped, tick each event you want sent. Each event also carries its own Send SUM parameter value switch, so you choose per event whether sum is appended. Click Save Integration.
The configuration is per account: there is no per-product or per-offer setup. The same postback URL and the same SUM Field are reused across everything you sell, which is what the screen means by “Configure once and reuse across all your offers”. If you sell as a creator and also promote as an affiliate, each role keeps its own RedTrack configuration. And when a sale comes through an affiliate, the platform fires the postback twice (once to the creator’s postback URL and once to the affiliate’s), each with its own SUM Field applied. For a conversion to be attributed in RedTrack, the RedTrack click id has to be present on the checkout link. The checkout captures the query string of the link that brought the buyer. The click id is read from that query string, from the following parameters, in priority order. The first one present wins: Parameter names are matched exactly, and matching is case-sensitive: clickid and ClickId are both read, CLICKID is not.
Use ?clickid={clickid} on your checkout link, with RedTrack’s own {clickid} macro filling the value.
subid is not an accepted parameter. It is a common name in RedTrack link templates, so it is the most frequent reason a click id never reaches the platform.If none of the accepted parameters arrives on the checkout link, the postback is not sent at all and no row appears in the delivery logs. There is no visible error: the event is silently skipped.
The click id survives even though it is not one of the tracking parameters returned on webhook payloads. RedTrack reads the raw captured query string, not the filtered trackingParameters object, so clickid works here even though it never appears in a webhook body.

The postback URL and its macros

The URL saved under Postback URL is a template. Any {field} token in it is replaced with the matching value from the event at send time. Five behaviors to know when you build the template:
  • type and currency are always appended to the final URL, whether or not you put them in the template. Adding them yourself sends them twice.
  • sum is appended when Send SUM parameter value is on for that event. If the URL RedTrack generated already ends with &sum={...}, the platform removes that copy before appending its own, so there is no duplicate. A sum written without braces (&sum=100) is not removed.
  • Values are URL-encoded, so an email arrives as jane.doe%40example.com.
  • Empty buyer fields are dropped from the URL instead of arriving blank. This applies to first_name, last_name, phone, email and zip_code, and only when you keep the default naming: &email={email}. If you rename the parameter, as in &e={email}, it is not dropped.
  • A token that matches no macro is left as literal text. It goes out on the URL exactly as you typed it, braces included. That also happens to {items_total}, {transaction_total} and {creator_net_amount} on Checkout Initialized, because those amounts do not exist yet at that point.
With this template:
an approved purchase, with SUM enabled and the SUM Field set to Products Total (Gross), produces:
and a checkout start, on the same template, produces this instead (email is empty at that point, so it is dropped):
The buyer macros put personal data (name, email, phone, ZIP code) into a URL that RedTrack receives and logs. Include them only if you actually use them on RedTrack’s side.

Events sent

Upsells and downsells have no toggle of their own. Enabling Purchase enables all three, and you tell them apart by the type value.

The SUM parameter

sum is the amount of the operation reported to RedTrack. The SUM Field you picked when configuring the integration decides which amount that is. The value is a decimal amount in the transaction currency, not in cents, and it is not zero-padded: a $294 sale arrives as sum=294, not sum=294.00. Affiliates on a fixed commission (CPA) are a special case: the amount sent is always the affiliate’s commission, whatever the SUM Field says. The platform overrides the selection on its own, so there is nothing to configure for that case. Which one to choose:
  • To see the ticket of the sale in RedTrack, pick Products Total (Gross).
  • To see the commission in RedTrack, pick Net Amount.
  • On a fixed commission (CPA), pick anything: the commission is what gets sent.
  • Turn SUM on for Purchase only. At checkout start there is no sale amount yet, so sum goes out as the literal text {items_total} rather than a number.

Delivery logs

Each integration has its own View Logs screen with the delivery history: Each attempt waits up to 5 seconds for RedTrack to respond, and a failed attempt is retried up to 3 times before the delivery is recorded as failed. Read an empty log carefully. A row is written only when the postback is actually attempted, so no row at all means one of three things happened before the send: the click id was missing from the checkout link, the RedTrack integration was not configured on that account, or the event was not enabled. An empty log is a diagnostic, not evidence that delivery failed.

Troubleshooting

The most common cause is the click id: missing from the checkout link, or arriving under a parameter that is not read, subid above all. In that case the postback is never attempted and nothing is logged. Check The tracking link and confirm the link carries one of the accepted parameters.The other two causes are the integration not being saved on that account, and the event not being enabled on the Events to be mapped list.
The click id reached the platform but does not exist on RedTrack’s side. This happens when the campaign is not routed through the RedTrack tracking link for that domain, so no real click id was ever issued for that visit.
If the click id field in your RedTrack traffic source uses the wrong macro ({click_id} instead of {clickid}, for example), what reaches the checkout is the macro text itself, not a click id.Pasting the link with the macro straight into a browser does not test this either. Outside a real click coming from the campaign, RedTrack does not substitute its macros.
You are reporting the ticket when you meant the commission, or the other way round. Review The SUM parameter and change the SUM Field.
Only the macros in the table above are substituted. Any other token stays on the URL as literal text, braces included.

FAQ

Nothing. You do not need to include sum at all: the platform appends it on every postback where SUM is enabled for the event, and fills it according to the SUM Field you chose. If the URL RedTrack generated already ends with &sum={...}, the platform removes that copy first, so there is no duplicate.
No. Every value travels as a query parameter on the GET URL. There is no request body.
Per account. One postback URL and one SUM Field cover every product and offer you sell. If you act as both creator and affiliate, each role has its own configuration.
No. They ride on the Purchase toggle and are distinguished by the type value, upsell and downsell.

Need help?

Our team can help you set up your integration: support@pagamerican.com