Keep three percentage denominators visible in a signal cross-tab

I maintain this Actor. This is an AI-assisted technical walkthrough checked against the installed source contract.

A cross-tab becomes misleading when a cell percentage arrives without its denominator. Two accepted enterprise observations can be most of an enterprise sample and still represent a minority of the complete export. I want the counts and all three interpretations available together before anyone pastes a percentage into a slide.

US Brand Signal Cross-tabulator accepts one to 100 rows with unique row IDs and two explicit categorical dimensions. Each dimension supports at most 15 distinct values. Its identifiers are bounded ASCII tokens. This is a compact counting step for an already prepared dataset; the labels have the meaning your upstream process assigned them.

Work through a five-row example

The input below contains three enterprise observations and two startup observations. Enterprise has two accepted rows and one review row. Startup has one accepted row and one rejected row. These are synthetic categories, chosen so the denominators can be checked by hand.

For the enterprise/accepted cell, the count is two. Its row share is two divided by three, its column share is two divided by three accepted observations, and its overall share is two divided by five. The corresponding rounded basis-point values are 6667, 6667, and 4000. A basis point here is one hundredth of a percentage point; 4000 means 40 percent. The matching denominators in this example are a coincidence, not an invariant.

The full matrix also retains combinations with zero observed rows. Startup/review therefore remains an explicit zero cell. That is useful when a downstream chart would otherwise silently remove an unobserved category combination. It is still a zero within this submitted dataset, with no claim about a wider population.

Keep duplicate policy upstream

Two records with the same dimensions and different row IDs contribute twice. Repeating a row ID is rejected. Decide whether a row represents an event, an account, or a manually reviewed item before export. Replacing IDs merely to get validation to pass would preserve accidental double counting.

A practical review packet contains the input file, its observation window, a short dimension dictionary, and the generated report. Check that matrix counts sum to the input count, that row totals reconcile, and that column totals reconcile. A different input population requires a new explanation even if the category names stay identical.

Use the report for a bounded operations comparison, such as a queue export split by segment and review outcome. It does not calculate statistical significance, correct sampling bias, or establish that one segment performs better. Those questions need additional evidence and a declared statistical design.

The useful handoff is a table with visible counts and denominators, plus the upstream definition of one observation. That lets another analyst reproduce the arithmetic without having to trust the chart title.

Input and execution boundary

Save this workflow-specific contract example as input.json. This is a synthetic contract example for the workflow described above; it does not assert a real observed business event.

{
  "schemaVersion": "1.1",
  "rows": [
    {
      "rowId": "observation-001",
      "rowDimension": "enterprise",
      "columnDimension": "accepted"
    },
    {
      "rowId": "observation-002",
      "rowDimension": "enterprise",
      "columnDimension": "review"
    },
    {
      "rowId": "observation-003",
      "rowDimension": "startup",
      "columnDimension": "accepted"
    },
    {
      "rowId": "observation-004",
      "rowDimension": "startup",
      "columnDimension": "rejected"
    },
    {
      "rowId": "observation-005",
      "rowDimension": "enterprise",
      "columnDimension": "accepted"
    }
  ]
}

A deliberate cloud execution can use the following asynchronous request. It creates a new run and may incur charges; this walkthrough did not execute it.

curl --request POST \
  'https://api.apify.com/v2/acts/zinin~us-brand-signal-cross-tabulator/runs?build=0.2.2&timeout=180&maxTotalChargeUsd=0.10' \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header 'Content-Type: application/json' \
  --data-binary @input.json

Save the returned run ID. Check that existing run before retrying after a client timeout, then inspect its terminal status, Dataset, and KVS OUTPUT. A timeout in the caller does not cancel a server run. The charge ceiling bounds the request; it does not guarantee delivery or remove the start event. The build selector pins the observed build number, while the run's actual build ID should be retained for provenance.

Price and reproducibility

On 19 October 2026, the observed FREE-plan rates are $0.005 for the automatic start event and $0.01 per complete delivered report. The platform can count start events according to allocated memory. Other subscription tiers differ. Verify the current Actor page before purchasing a run; optional external services, where enabled, are separate.

This article uses the installed 0.2.2 source contract and saved public input shape, checked on the stated date. The arithmetic examples are explanatory, not fresh cloud acceptance, customer activity, or evidence of revenue. Preserve your input, actual build ID, observation boundary, and terminal receipt when adapting the workflow.