Browser & Server Event Identity Batch Evidence

Compare an authorized batch of browser and server event observations after a tracking integration change or a recurring debugging export. This Actor groups exact event identities, counts repeated observations and creates a traceable report of reused keys and independently declared action conflicts. It works with supplied JSON or mapped CSV and needs no Meta credentials.

The output describes the evidence you provide. Both sources observed with one identity does not prove that Meta deduplicated the events. Missing counterparts in a sample remain unknown. The Actor does not send conversions, read an account, estimate attribution loss, calculate a global match rate or change an integration.

Prepare your observations

Supply snapshotId, an opaque batch label, and an explicit batchCoverage choice: sampled for a partial or debugging export, or complete when you declare that the supplied batch covers the intended scope completely. That declaration is retained in the report and is not independently verified.

Use an events array. Each object is one observed event, with these fields:

Field	Meaning
rowId	Unique opaque identifier for the input observation
datasetId	Exact pixel or dataset scope identifier
eventName	Exact event name; case is preserved
eventId	Exact string ID; omit, use null or an empty string when unavailable
source	Exactly browser or server
actionId	Optional opaque logical-action ID that you independently know

Never derive actionId from eventId, timestamps, row order or a guess that two similar rows refer to the same purchase. Leave it missing when the independent relation is unknown. Use only authorized, opaque identifiers: no contact details, cookies, raw event payloads or secrets. Inputs and reports are stored in your Apify run; this is not browser-only local processing.

A short example:

{
  "snapshotId": "integration-change-001",
  "batchCoverage": "sampled",
  "events": [
    {"rowId":"01","datasetId":"pixel-001","eventName":"Purchase","eventId":"0001","source":"browser","actionId":"known-action-A"},
    {"rowId":"02","datasetId":"pixel-001","eventName":"Purchase","eventId":"0002","source":"server","actionId":"known-action-A"}
  ]
}

These rows provide an observed ID mismatch for one independently declared action. They do not establish whether either event was accepted or attributed by a platform.

For CSV, remove the events field and supply eventsCsv. Canonical headers are rowId,datasetId,eventName,eventId,source,actionId. The first, second, third and fifth headers are required; ID headers may be absent. Set eventColumns with all six distinct mappings to use different header names. BOM, quoted commas and quoted multiline fields are supported. Duplicate headers, undeclared columns, irregular rows and duplicate row IDs are rejected. A CSV record is one observation: summary rows with browser/server count columns must be expanded into uniquely identified observations before running; counts are never guessed or expanded automatically.

Interpret the evidence

An identity is the exact tuple of datasetId, eventName and a nonempty eventId. Different names and datasets remain separate. Each missing event ID stays separate. Identity rows contain source counts, original row IDs and source references, known action IDs, unknown-action counts, explicit counterpart evidence and findings.

A shared identity assigned to two distinct known action IDs is a reused-key conflict. Unknown action IDs leave reuse unresolved. Repeated browser or server observations are flagged for review; this report cannot distinguish retries, repeated collection and multiple actual sends. Action groups are scoped to dataset plus independently declared action ID, expose differing observed source ID sets or names, and retain incomplete comparisons as unknown. No timing acceptance window is applied.

Download the report

Each completed run produces one dataset item with the full report, plus OUTPUT JSON, flat identity evidence.csv, findings.csv and downloadable report.html in the default key-value store. JSON and HTML include action groups and the complete supplied observation ledger. The HTML contains escaped data and no external scripts. CSV cells that resemble spreadsheet formulas are neutralized; original exact values remain in JSON. Logical CSV record references count data records, not physical text lines.

The limit is 2,000 observations and 4 MB total JSON input. Full JSON must remain below 8 MB and each export below 9 MB; output bounds are checked before charging. Use smaller batches for larger ledgers.

Price and recovery

The published price is $0.25 per completed report, with platform usage included. The single billable event is report-completed; there is no positive startup or dataset-item charge. Invalid input or a budget below one report creates no charged report. A new run of the same input is a new report and is billable again. Resuming a saved run verifies its input and result integrity, restores missing exports and retains one dataset item and one report event. Partial exports may exist after interruption; resume the same run to complete delivery.

Use the report to prepare an evidence ledger for manual integration debugging. It does not certify tracking health, fix source instrumentation or replace a platform's own diagnostics and acceptance results.