Shopmetrics

The marketing site for Shopmetrics CX, the mystery shopping and audit platform Research Metrics sells to fieldwork, audit and research providers.

What they came with

Shopmetrics does not sell one product. It sells a suite that a fieldwork firm buys in pieces: a portal for field agents, analytics for the end client, a survey builder, action plans, microlearning, a partner network and a gig marketplace. A visitor arrives wanting one of those, and the site has to get them to it without making them read nine pages first. The same pages also have to speak to a buyer working with the Ohio entity and one working with the Bulgarian entity, and carry blog posts that are written inside the platform rather than in a content system built for the web.

What the build had to do

A nine-tile index of the suite

The home page closes on a grid of nine module tiles: Field Portal, Shopmetrics CX, CX Analytics, GigSpot, Surveo, Aptivate Microlearning, Partner Network, Dataverse CX and Actionate Action Management. Each links either to its own page or to an anchor on the platform page, so the grid is the site's real table of contents and its labels have to match the names a customer will meet inside the product.

Module copy that works twice

The Products menu points at four solution pages; the platform grid points at anchors in one long stack of ten sections. The same module text therefore has to read as a standalone page and as one section among many, which means no section can lean on the one above it for context.

Blog records from the platform

Posts do not come from a blogging tool. They arrive as a typed record set embedded in the page, each record carrying a title, an object name, a subtitle, a summary, a posted date, a visibility value and a summary-image block, and the card grid is assembled from those fields at load.

One demo form, two round trips

Contact_Us.asp holds the only demo form and every page routes to it. The submit path posts the reCAPTCHA response to Contact_Send.asp for verification first and only then posts the message to the same handler, so the form has to hold its own state across two requests and report either outcome in place.

Two entities in one footer

Research Metrics LLC in Sylvania, Ohio and Shopmetrics Europe Ltd. in Varna share the footer with the association and partner marks. The block has to read as one company with two addresses, on every page, without a region switch.

Technical detail

Typed entity payload on the blog

Blog.asp inlines a `window.articlesData` object with three parts: a manifest carrying pagination state and page size, a schema, and the records. The schema is the platform's own object model, with field data types (Text, Categorical, Temporal, Relationship), an N:N relationship to a Blogs entity through a named join, and per-record `uuid` plus `versionUuid`. The marketing site inherits the application's field definitions rather than a CMS's, and images referenced from the editor markup resolve through a separate attachment service on the application host, addressed by id rather than by file path.

Cards built in script from editor markup

The card image is not a plain URL field. `renderArticleCards.js` writes the `SummaryImage1` block into a detached div, queries it for the first `img` and takes that src. The manifest ships no ordering, so the same script sorts the records by DatePosted, gates them on `Visibility[0].name == "Public"`, lifts the newest public post out for a wide hero card before the remainder fall into thirds, and splices a subscribe tile in ahead of the fourth public post. Ordering, gating and layout are all decided in one pass over the payload.

Deferred images, script-built grid

Home and platform sections ship their imagery as empty divs carrying `data-lazysrc`, swapped in after load, so first paint is markup and CSS only and the long product stack costs nothing until it is wanted. The blog grid is the opposite trade: it exists only once the script has run, which is why the payload is inlined in the document rather than fetched.