Skip to content
Back to the journal

Know your numbers

Check a client report for content from another account

Check the agreed account, period, fields and complete row set across a report and its attachments before handing it to a client.

The short answer

Define which account, period, rows and fields the recipient may receive. Compare every delivered artifact with that contract, including embedded data and downloadable tables. A correctly branded chart can accompany another account’s rows. Keep content inspection, permission to share and actual destination access as separate checks; a local file check cannot certify the server’s authorization.

What you’ll take away

  • A client name on the cover does not establish which records are inside.
  • Check required rows as well as unexpected rows; an empty report is not a successful delivery.
  • Hold unknown ownership and unsupported file formats rather than declaring them clean.

Write the boundary before exporting

For an authorized client report, record the recipient, account or Page reference, observation period, metric definitions and permitted fields. State whether the report covers all eligible posts or a declared subset. Keep a minimal private list of expected record keys from the approved source. A shared agency login, matching display name or copied template is not a reliable account boundary.

The completion question is practical: does this exact delivery contain the intended client’s complete agreed material, with no known out-of-scope content? That differs from choosing a white-label design or checking join cardinality. It also differs from making an anonymous public aggregate. A report can have correct arithmetic and still be the wrong client’s report.

Inspect the files behind the visible chart

Inventory the actual export: report, table, data attachment, image description, notes and any linked destination. Read the delivered versions, not only the design canvas. Some formats retain data that the visible chart does not show. In our supplied SVG exercise, the visible total is correct while a metadata element contains the wrong account’s record. This is a deliberately constructed file, not an observed defect in a real reporting product.

Use a positive field list and exact scoped keys where the source supports them. Reconcile record multiplicity and values, not only a deduplicated set of IDs. A renamed field, unsupported format, missing owner or uninspected image needs a separate unresolved line. Searching for one client name cannot establish that every other representation is absent.

Trace the same three source rows through the packet

The original teaching source has A1 and A2 for fictional account A, with 120 and 80 impressions; B1 belongs to fictional account B and has 300. All use the same invented October period. The agreed A delivery contains exactly A1 and A2 and totals 200 impressions. JSON, CSV and SVG metadata are three representations of those same two rows, not six independent posts.

Run the included standard-library Python checker from the extracted packet. It reads the actual generated files, compares the permitted field names, account, period, exact row multiplicity and full values, then checks the total. The checker is intentionally limited to these supplied schemas and fixtures. It does not accept arbitrary client files, parse PDFs, inspect raster images or contact a production service.

Constructed deliveryVisible appearanceActual decision
Complete A filesA total 200All three representations match the two expected rows
Foreign SVG metadataA total still 200Hold: metadata also contains B1
A2 missing from CSVOther files still total 200Hold: CSV has only A1 and totals 120
Unknown owner in JSONA-shaped reportHold: ownership cannot be established
Two fictional account A rows total 200. JSON, CSV and SVG metadata must retain exactly those rows. Foreign, missing and unknown-owner variants are deliberately held.
Original constructed exercise. Complete cases and inputs are in the packet; no real account or reader test.

Repair the scope before copying a passed label

D1 — A chart is branded for A, but its embedded rows include B1. Remove the stale data through the authorized source/export process, regenerate the affected delivery and inspect it again. Editing a logo or hiding the chart legend does not repair the data. The supplied checker demonstrates this failure locally; no real client received the exercise.

D2 — A CSV contains no B rows, but A2 is missing. The absence of a foreign record is insufficient: reconcile the two expected A records and total 200. D3 — One row has no established owner. Keep it outside the released delivery until an authorized source resolves that attribution; do not assign A because its metric happens to fit the total. A plausible sum is not ownership evidence.

Check sharing permission and access separately

OWASP recommends default denial and permission checks for each request, including protected static resources. We use that distinction to explain why inspecting a local export cannot prove who can retrieve its hosted copy. Opaque URLs and a successful owner-session download do not establish recipient isolation. Review the actual authorized destination with the responsible service owner; do not probe unrelated accounts or guess other clients’ links.

Record the approved recipient, sharing basis, access scope and actual observed delivery state. A draft link, uploaded file, sent invitation and confirmed intended-recipient access are different states. If access testing is unavailable, retain that gap. Likewise, a successful content check does not establish contractual permission, a complete security audit or that previously distributed copies were recalled.

Keep a short receipt for the exact delivery

Use the editable record for the source version, expected keys and fields, each artifact’s version, content decision, unresolved formats, recipient and destination check. Keep private identifiers out of a public report. A byte fingerprint can distinguish same-named files, but its meaning still depends on the source and inspection that produced the receipt. Do not keep unnecessary client data merely to make the receipt longer.

The packet contains all three source rows, four actual local delivery variants, their checker results and blank English/German records. All accounts and values are fictional. The result demonstrates a bounded reproducible export inspection, with no real account access, server authorization test, independent review, reader outcome or customer-value claim.

  1. Declare the authorized delivery contract.
  2. List the exact exported artifacts and supported inspections.
  3. Reconcile complete scoped rows, fields, values and totals.
  4. Repair or hold every unresolved artifact.
  5. Check the actual authorized destination and retain its separate status.

Sources & product references

Product details reflect the publication date. External features and interfaces may change.

WRAPPED.LI

Your year has a story. Find yours.

Explore your available activity, see the people behind it, and choose what to share.

Create my recapStart with a free profile preview. Premium is optional.
Wrapped.li editorial

Product guidance from Wrapped.li. Numerical examples are illustrative, not customer results. LinkedIn is a separate company.