Troubleshooting Adgora Campaign Duplicate Conversions After Postback

Adgora Campaign Duplicate Conversions After Postback: A Troubleshooting Comparison

A conversion can appear twice even when a visitor completed the action only once. The extra record may come from a repeated postback, a receiving endpoint that accepts the same event more than once, or reporting that counts one event in two places. Before changing campaign settings, trace the full path and identify where the second record first appears.

This comparison focuses on three ways to prevent duplicates: event-ID deduplication, transaction-ID checks, and time-window rules. The right choice depends on what identifiers your integration provides and whether customers can legitimately convert more than once. A rule that removes duplicates too broadly can erase real sales or sign-ups.

Set criteria before comparing fixes

Judge each fix against three criteria: does it block a repeated event, does it preserve legitimate repeat conversions, and can you test it without disrupting live campaigns? Write those criteria down before adjusting the postback flow. Otherwise, a lower conversion count may look like a success even if the rule has suppressed valid activity.

Define what counts as a duplicate for the action you are measuring. For a one-time checkout, the same order recorded twice is likely a duplicate. For a subscription renewal, two purchases by the same customer at different times may both be valid. Make the definition specific to the event, not just the campaign.

Keep the records needed to compare outcomes: the source event, any event or transaction identifier, postback attempts, endpoint responses, and Adgora’s conversion report. If a field is not available, record that gap rather than assuming two records refer to the same action. A small test log is more useful than a vague claim that conversions “look inflated.”

Trace one conversion through the postback path

Pick one reported conversion and follow it from the original action to the reporting view. Start with the source event, such as an order confirmation, form submission, or app action. Note its timestamp and any identifier attached at that point. Then find the corresponding outgoing postback and the record at the receiving endpoint.

Compare the identifiers and timestamps at each step. If the source has one event but the endpoint has two matching records, the second record entered somewhere between postback delivery and endpoint storage. If the endpoint has one record but Adgora shows two conversions, investigate the reporting or import path instead of changing endpoint deduplication.

Look for a specific point of divergence. For example, a browser event and a server-side event might both report the same checkout, or a retry might reach an endpoint that stores every request as new. These are different failure patterns and call for different fixes. If both paths carry a shared event identifier, they may be easier to reconcile; if they do not, you may need to add one at the source.

Record the path in order: source event, postback generation, delivery attempt, endpoint response, stored record, and Adgora report. This gives the team a concrete sequence to test. It also prevents a common detour: blaming the campaign before checking whether the endpoint has already created two records.

Compare deduplication strategies side by side

Event-ID deduplication is usually the clearest option when the same conversion can carry one stable, unique event identifier from source to receiver. The endpoint stores the first event and treats a later request with the same ID as already processed. Check that the ID remains unchanged through retries and through any browser or server paths that can report the same action.

Transaction-ID checks can work well for purchases when each order has a stable reference. They are less suitable for a lead form, trial start, or another event that does not naturally produce a transaction ID. Also check the scope: a transaction reference may be unique only within one account or store, so the deduplication key may need that context too.

Time-window rules are a fallback when the integration lacks a stable event or transaction identifier. They can treat matching conversions close together as one, but “close together” is not the same as “the same event.” A customer might complete two valid actions within the chosen interval. Choose the narrowest interval that addresses the observed duplicate pattern, then test legitimate repeats before applying it broadly.

For teams reviewing campaign measurement more widely, the same discipline applies to traffic sources and conversion definitions. Adgora’s crypto ad network targeting options guide can help frame targeting choices, but targeting changes will not correct a duplicate created after a postback reaches the endpoint.

Check retry and response behavior

A timeout does not prove that a postback failed. The endpoint may have stored the event but failed to return a clear acknowledgment, leading the sender to try again. Confirm how the sender handles timeouts, which response codes trigger retries, and whether the endpoint returns a response only after saving the event.

Inspect the actual request and response logs before attributing duplicates to retries. Check the number of attempts, timestamps, response codes, and whether each attempt carried the same event identifier. Then confirm the endpoint’s documented behavior in the environment you use.

There is a practical distinction here. If every repeated request has the same ID and the endpoint stores both, the receiving side may need idempotent handling. If the repeated requests carry different IDs for one source action, investigate where those IDs are being generated. A retry policy alone cannot explain that mismatch.

Test fixes against duplicate and repeat-event cases

Use two controlled cases before deploying a rule. First, send the same conversion postback twice with the same identifier. The expected outcome is one stored conversion. Second, create two legitimate conversions with distinct identifiers, such as two separate orders, and confirm that both remain visible.

Compare the source log, delivery log, endpoint records, and Adgora report for both cases. A fix passes only if it removes the repeated event without removing the valid second event. If you use a time-window rule, test the repeat case within the proposed interval; a test outside it will not reveal whether the rule is too broad.

Keep the test isolated from live optimization where possible. Use a test campaign, a staging endpoint, or a clearly marked test event so that the result does not affect campaign decisions. If a production check is unavoidable, agree on the test event and observation period with the people responsible for reporting before sending it.

For campaigns that also track app actions, make sure the test reflects how those events are sent. A separate overview of crypto advertising for app install campaigns may help with campaign context, but the duplicate check still needs to follow the specific install or in-app event through its own postback path.

Roll out with a rollback plan

Start with a limited rollout: one event type, one endpoint, or one test campaign. Before changing the rule, save the current configuration and note the baseline counts for source events, delivered postbacks, endpoint records, and reported conversions. Without that baseline, a later drop is difficult to interpret.

Monitor both sides of the problem. A lower duplicate count is positive only if legitimate conversions remain intact. Watch for missing records, unexpected drops in repeat purchases, rising delivery errors, or a gap between endpoint storage and Adgora reporting. If any of those signals appears, pause the change and compare the affected event IDs or transaction references.

Set a clear rollback trigger before launch. For example, revert if a known test conversion is suppressed or if valid repeat events disappear from the endpoint log. Keep the old rule available until the new one has been checked against real campaign records.

Document what changed, when it changed, and which event types it covers. That record helps separate a postback fix from unrelated campaign edits. It also gives the next person a direct way to restore the prior behavior if the conversion count shifts unexpectedly.

Verdict: prefer event-level identity when available

Use a stable, unique event identifier when the integration supports it and the same identifier can travel from the source event to the receiving endpoint. It gives the receiver a direct way to recognize a repeated request without treating every nearby conversion as a duplicate.

If no suitable event ID exists, use a transaction ID for purchases where that reference is reliable. For other events, a time-window rule may be the narrowest available fallback, but validate it against legitimate repeat conversions before rollout. In a case such as Adgora campaign duplicate conversions after postback, the best fix is the one that removes a repeated record while preserving the second real action—not the one that simply produces a smaller total.