Where HQ reputation numbers come from (and what HQ never sees)

What this article covers

The Reputation board shows you a composite score, a star rating, and a review count for every franchisee in your network. This article is the technical companion to that overview: it traces those numbers back to where they actually start, on a franchisee's own connected Google and Yelp profiles, explains the nightly process that turns them into the network-wide board you read, and spells out exactly what HQ's side of the platform can and cannot see along the way.

Where to find it

Open Reputation from the HQ sidebar at hq.verinode.ai/reputation. Everything traced in this article feeds the hero panel and the four franchisee rows (Below Threshold, Declining Trend, Top Performers, Most Reviewed) on that page, plus the franchisee reputation detail slider you open by clicking any tile.

Two schemas, one narrow bridge

Verinode's database is split by trust boundary, not by feature. A franchisee's own operating data, including its connected review platforms, lives in pii.*, the schema HQ's application server has no grant into at all. HQ's pages read from core.*, a separate schema that only ever holds pre-computed, per-office rollups. There is exactly one process allowed to read across that boundary: a nightly, scheduled aggregator job (internally, hq-aggregate-refresh) that runs with its own elevated access, reads a franchisee's platform ratings, computes a derived figure, and writes that figure, and nothing else, into core.*. HQ's server never queries a franchisee's pii.* records directly, on Reputation or anywhere else.

That single job is the reason a review's actual star rating can reach HQ as a network number while the review's actual text never can. The aggregator's reputation step only ever reads two columns per franchisee, per platform: the average rating and the total review count. It has no code path to a review's written content, a reviewer's name, or anything else in a franchisee's account.

What a franchisee connects, on their own side

On a franchisee's own IQ Reputation page, they can connect up to five platforms: Google, Yelp, BBB, Trustpilot, and Facebook. Connecting a platform is what populates that franchisee's per-platform average rating and review count, the only two figures the HQ aggregator ever reads. Disconnecting a platform is a soft removal on the franchisee's side (their existing reviews stay in Verinode, they just stop appearing on their own page), and it also means that platform stops contributing a rating to the next night's HQ rollup.

The nightly aggregation, step by step

1. 1Read each active franchisee's per-platform ratings. For every operator in your group's roster, the aggregator reads that operator's Google rating and review count, and Yelp rating and review count, from the franchisee's own reputation data. A franchisee with no connected platforms yet still gets a row, with every rating field left null, so the board can render an explicit "no data" state for that franchisee instead of silently leaving them out.
2. 2Compute the composite score. Each available platform rating (Google, Yelp) is scaled from its native 5-point star scale to a 100-point slice, and the composite is the average of whichever slices exist. A franchisee reporting only a Google rating gets a composite built from Google alone; one reporting both gets an even blend of the two. A franchisee with neither connected yet gets no composite at all, not a zero.
3. 3Attach the franchisee's registered name. The aggregator looks up the franchisee's location name from your network's member roster and carries it onto the rollup row, both in plain text and encrypted (see below), so the board can label each tile without a second lookup at read time.
4. 4Upsert one row per franchisee. The result, one row per (your group, that franchisee), is written to the network reputation table. A franchisee always has at most one current row; the next night's run replaces it rather than appending a new one, so what you read on the board is always the latest computed state, not a running history.

This runs as part of a single scheduled overnight sweep across every group in the network, alongside the other per-section rollups (Facilities, Fleet, Commercial, and the rest). Because a network can have many groups and each one takes real work to compute, the sweep checkpoints its progress and can resume on its next scheduled pass rather than silently dropping the tail of a long run. In practice, this means the Reputation board reflects last night's completed run, not a live read at the moment you open the page. There's no manual refresh button, if a number looks stale, it catches up on the next overnight pass.

A known gap: review trend isn't computed yet

The rollup row has a place for a review trend (improving, stable, or declining), and the Reputation board's Declining Trend row and the hero's improving/declining counts are both built to read it. Today, the aggregator always writes that field as empty. Computing a real improving/declining signal needs a longer history of each franchisee's ratings over time than the network-level rollup currently keeps, so it's deferred rather than approximated. Concretely, this means the Declining Trend row and the improving/declining counts in the hero subtext will currently read as empty or zero even on a network with real reputation data flowing in. This is a known, tracked gap, not a bug in what you're reading, and it resolves itself once the aggregator starts keeping that history, with no action needed on your side.

Franchisee-name encryption under the group's own key

The franchisee name attached to each rollup row isn't just carried as plain text. Every write to the reputation rollup, and to the equivalent rollup tables for Facilities, Fleet, Commercial, and the rest, encrypts that same name a second time under your group's own encryption key: a key generated for your group specifically, wrapped by Verinode's key-management layer, and unwrapped only at the moment a page needs to decrypt it. It is never a single platform-wide secret shared across every network.

When the Reputation board (or the detail slider) needs to show a franchisee's name, it unwraps your group's key once per page load and decrypts the name from the encrypted column. If that decrypt fails for any reason, or your group hasn't been provisioned a key yet, the page falls back to the plain-text copy of the same name so the board still renders correctly either way. What you see never depends on which of the two paths resolved.

Entity-model name anonymization

Separately from encryption, your network has a Data posture setting (Settings → Network → Data posture, admin-only) that controls whether a franchisee's identity is exposed at all on HQ pages that drill into individual operators, including the franchisee reputation detail you open by clicking a tile. Two modes:

• Independent operators (the default for every new network, marked "Default · privacy-safe"). Use this for franchise networks, associations, co-ops, and PE roll-ups, where each operator is a separate legal entity. Opening a franchisee's reputation detail labels it with a stable anonymized handle, Franchisee #XXXX, derived from that operator's account ID, instead of its registered name. City, state, and contact email are hidden the same way. The composite score, star ratings, and review counts underneath are unaffected, aggregate metrics keep flowing in full either way.
• Same entity, for an enterprise operating every location under one tax ID. There's nothing to anonymize here, an enterprise's own regional offices are its own data, not a peer's, so the franchisee reputation detail shows the real registered name throughout.

Only an HQ admin can change this setting, and a change applies network-wide on the next page load, there is no per-franchisee override.

Peer comparison inside the detail slider

Opening a franchisee's reputation detail also lets you compare that one franchisee's composite score, Google rating, Google review count, Yelp rating, and Yelp review count against the rest of your network, using the Group scope in the switcher at the top of the slider. That comparison is built entirely from numbers, a median and a percentile rank, and never surfaces another franchisee's name, rating, or identity alongside it. Group scope only becomes available once your network has enough active franchisees reporting reputation data to build a comparison without the result being traceable back to one specific peer; on a network too small to clear that bar, the switcher marks Group as unavailable and explains, in the same plain language shown on screen, that the comparison needs more active franchisees in the network before it can unlock. Regional and National scope are visible in the same switcher but not yet turned on for reputation metrics: selecting either currently reads "Industry benchmarks not yet seeded for reputation metrics."

The strict boundary, stated plainly

Put the pieces together and the boundary is this: HQ's Reputation board and detail slider ever show a composite score, a per-platform star rating, a per-platform review count, a BBB grade, and (once it ships) a trend direction, every one of them a number computed once a night from a franchisee's own connected platforms. HQ never receives, and has no code path to receive:

• The text of a customer's actual review, or that reviewer's name. Raw review content lives in the franchisee's own operating data; the aggregator that feeds HQ only ever reads a platform's average rating and review count, never an individual review row.
• Any other business record belonging to the franchisee, financial, operational, or otherwise, through this pipeline. The Reputation rollup carries reputation figures and a name, nothing else.
• A path to reverse the encrypted name back to plain text without your group's own key, or to read it at all without going through the one aggregator process authorized to write it.

This is the same commitment that runs through every HQ surface: franchisees own their data, HQ sees the network's standing and trend, and the boundary between the two is enforced by where the data physically lives and which process is allowed to touch it, not by a display setting anyone can switch off.

Best-practice example

Say a franchisee in your network connects their Google Business Profile for the first time on a Tuesday afternoon. That evening's aggregator run reads their new Google rating and review count, computes a composite from Google alone (they haven't connected Yelp), and writes one row into the network reputation table with their encrypted name attached. On Wednesday morning, that franchisee appears on your Reputation board for the first time, in whichever row its composite score and review count qualify it for. If your network runs Independent operators posture, clicking that tile opens a detail view labeled with an anonymized handle rather than the franchisee's real name, even though the same tile on the board itself already showed you exactly who it was, your own roster is never the thing being protected, the peer-comparison layer inside the detail view is.

Related reading

• Reputation: network review health at a glance, the full walkthrough of the board this article's pipeline feeds
• What HQ sees: the network privacy boundary, the platform-wide statement of the aggregates-only boundary this article makes concrete for Reputation
• Where the numbers come from: the aggregator and empty states, the same nightly-aggregator and encrypted-rollup pattern applied to Margin & Cash
• What HQ sees on Commercial, and what it never does, the same Data posture setting and anonymization handle applied to a different section
• Network health, for the platform-wide aggregates-only doctrine
• HQ overview, for where Reputation sits among HQ's other network-intelligence sections