Define a reporting contract
A social media metric dictionary records what a measure counts, its source field, denominator, scope, and transformations. A dictionary should prevent recurring disagreement about review numbers. Start with measures used for decisions rather than every available field. Identify each measure's business question and owner. If nobody can explain what action depends on it, reconsider its prominent place in the report.
Separate source field and business label. A friendly name helps readers; the exact source field makes reconciliation possible. Record whether the value comes from a native interface, authorized export, API, or internal calculation. Surfaces can expose related but different definitions. Make that distinction explicit rather than treating the displayed name as a universal standard.
The LinkedIn Page content analytics definitions [2] describe native content measures. A social media analytics metric dictionary should retain each original field beside any reader-friendly label and document transformations so a colleague can reproduce the calculation without guessing its meaning.
Include enough lineage for another analyst to reconstruct the result without asking its author. This includes the account and object scope, filters, extraction date, transformation rule, and source version when relevant. A contract that depends on unwritten analyst memory will fail when responsibility changes.
Specify units and time behavior
Write the counting unit: event, item, account, unique audience unit, session, case, or currency amount. Then specify time scope. Lifetime activity for content published this month differs from all activity this month on content of any age. State the reporting time zone and period boundaries. These details often explain apparently inconsistent totals.
Describe refresh behavior and processing delays relevant to the report. Keep last collection timestamp separate from activity date. A fresh retrieval may contain a provisional source value. Include paid treatment, exclusions, and eligibility conditions. If a field is unavailable for some formats or accounts, the dictionary should say so.
Add a reader-facing scope sentence that can appear beside the chart. An analyst may understand the field perfectly while an executive misreads it. The dictionary needs to support both readers, with a short explanation backed by a precise technical record.
Document formulas and permitted aggregation
For calculations, write formula, component definitions, rounding policy, and undefined-value behavior. A percentage needs a denominator. Currency requires a conversion basis and reporting currency. Retain unrounded components for reproduction. Display rounding should not silently become the input to later calculations.
Mark whether addition is valid across content, time, and accounts. These are separate questions. An audience measure can be valid for one period without supporting a sum across overlapping periods. A lifetime counter may permit a change calculation only under its source semantics and revision behavior. Write the supported operation rather than assigning “sum” to every numeric column.
Define missing and zero separately, including what happens during exports. A blank field can become zero through default spreadsheet logic. The contract should specify a value-status pair and block calculations that would imply observed inactivity when the actual state is unavailable.
Worked example: two monthly engagement totals
This example is hypothetical. A team reports 1,200 interactions on posts published in June, using lifetime values collected in July. Another report shows 900 interactions occurring during June on all available posts. Both are called “June engagement,” creating a dispute.
The dictionary renames the first “lifetime interactions for June-published content, collected July 7.” The second becomes “interaction activity during June.” Populations and collection dates are separate. The analyst does not force agreement by dropping older posts or subtracting later activity without a valid source field.
For creative comparison, the editor chooses a common seven-day observation window and records a third measure. Operations retains the activity-window measure for workload context. One dispute reveals three legitimate decisions with different definitions.
The QA reviewer reproduces one object from each population and checks its inclusion rule. A remaining discrepancy is recorded with a cause and owner. Renaming resolves semantic ambiguity, while reconciliation determines whether the implementation actually follows the contract. Both checks are necessary.
Maintain references and change versions
Attach the relevant official definition and date its review. Keep a note describing the interpretation active for the reporting version. When a field is renamed, removed, or redefined, identify dependent calculations and reports. The owner should approve migration and explain comparability breaks.
The Google Analytics Data API schema [1] is a primary reference for its fields. A social dictionary should likewise use the selected source's definitions where accessible, rather than inventing unavailable semantics.
Keep a changelog with old meaning, new meaning, effective date, reason, and affected reports. Decide whether history can be recalculated or needs a version label. A silent change can create a convincing trend about the reporting system instead of the audience.
Review references after permission changes, account migration, or source updates. A working collection job can still populate a field whose business meaning has changed. Successful retrieval and valid interpretation are separate acceptance conditions.
Test the dictionary against real disagreements
Include one worked calculation in the dictionary for each consequential custom ratio. Use invented values or an appropriately de-identified object, and show numerator, denominator, scope, and resulting value. This gives reviewers a concrete acceptance example and exposes ambiguous rules before they enter a report.
Use a concise reader definition beside charts and a detailed lineage record behind them. Reviewers should not need a technical file to discover that a figure is lifetime or provisional. Both layers should use the same metric identifier and version.
| Field | Purpose |
|---|---|
| Label and source field | Readable meaning and exact lineage |
| Unit and scope | What is counted |
| Time and refresh | Activity versus collection |
| Formula and aggregation | Valid ratios and totals |
| Missing treatment | Unavailable versus zero |
| Owner and version | Accountable changes |
Ask a colleague to reproduce an important metric and explain it to the decision owner. Turn missing scope, hidden filters, and uncertain aggregation into repair tasks. Avoid expanding documentation endlessly without checking whether it resolves real confusion. The dictionary is maintained successfully when it makes an actual report reproducible and its interpretation understandable.
Frequently asked questions
Must we document every metric?
Start with measures used in decisions and calculations. Expand when a new measure enters a report. A huge unmaintained catalog can be less useful than a smaller reliable contract.
Who owns the dictionary?
Assign a reporting owner with analyst and business-user input. Source changes require technical review; interpretation changes require agreement from the relevant decision owner.
Should old reports be rewritten?
Only through a documented revision. Recalculate when the evidence permits and comparability matters. Otherwise preserve the original version and mark the break so readers can interpret the change.
References and source scope
- Google Analytics Data API dimensions and metrics
Google Analytics web/app field definitions; not native social-platform metrics.
Source link checked 2026-10-03 - LinkedIn Page content analytics definitions
LinkedIn Page content metrics and sponsored scope; not a universal engagement definition.
Source link checked 2026-10-03