Group exact brand labels while keeping identity resolution explicit

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

Grouping by brand name can be useful without solving brand identity. A report that combines rows under the exact label Nike has counted a supplied string. It has not established a corporate hierarchy, resolved aliases, checked trademark ownership, or proved that every source record refers to the same entity.

US Brand Signal Brand Summary accepts one to 60 unique signal rows across at most 15 explicit brand labels. Each row carries its signal ID, brand name, event category, severity, active or resolved status, observation timestamp, and HTTPS source URL. The Actor canonicalizes the input and creates deterministic summaries for those labels.

Use a small synthetic export

The input below contains two Nike-labeled rows and one Apple-labeled row. Those familiar labels are synthetic demonstration data here, with example-domain provenance URLs. They do not describe a current announcement, price change, or risk event involving either company.

The Nike group contains a high-severity active product launch and a medium-severity resolved price change. The Apple group contains a critical active risk observation. A reviewer can reconcile those group counts directly against the three rows without interpreting an opaque score.

Recorded source URLs are preserved and deduplicated in the summary. The Actor does not fetch those pages. A syntactically valid HTTPS URL can be unavailable, unrelated, or supplied incorrectly. Keep source verification in your upstream process and name its observation time in the handoff.

Resolve aliases before grouping

Decide whether a legal name, a trading name, and a product label should share one reporting key. That decision belongs upstream. If two labels need consolidation, save the mapping and its owner before exporting the rows. If they must remain separate, retain that distinction explicitly rather than relying on a later reader to infer it from the brand names.

Unique signal IDs keep the same identifier from appearing twice in this input. They do not prevent two different IDs from describing the same underlying announcement. Establish an event identity rule in the source pipeline if deduplication across collectors matters.

The observation timestamp describes the supplied record. It does not automatically establish when the underlying event became effective. A delayed collection process can produce an observation date well after an announcement. Preserve that distinction when someone asks whether a summary describes a specific business period.

Hand off a reproducible summary

Save the input file, the brand-label mapping, the report digests, and the upstream collection window. Review the per-brand event, severity, and status counts before using them in an operations meeting. Explicit zero categories help a reviewer see which supported buckets have no submitted rows.

This workflow is a good fit for an authorized analyst export that already has resolved labels and documented provenance. It creates a compact evidence packet for human review. It does not estimate market size, choose authoritative sources, compare historical snapshots, or infer that a higher observation count represents greater commercial importance.

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": [
    {
      "signalId": "nike-launch-001",
      "brandName": "Nike",
      "eventType": "product_launch",
      "severity": "high",
      "status": "active",
      "observedAt": "2024-02-29T12:00:00Z",
      "sourceUrl": "https://example.com/nike-launch"
    },
    {
      "signalId": "nike-price-001",
      "brandName": "Nike",
      "eventType": "price_change",
      "severity": "medium",
      "status": "resolved",
      "observedAt": "2024-03-01T12:00:00Z",
      "sourceUrl": "https://example.com/retail/nike-price"
    },
    {
      "signalId": "apple-risk-001",
      "brandName": "Apple",
      "eventType": "risk",
      "severity": "critical",
      "status": "active",
      "observedAt": "2024-03-02T12:00:00Z",
      "sourceUrl": "https://example.org/apple-risk"
    }
  ]
}

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-brand-summary/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.