ChannelSight

🎓 Client reporting enablement

• •Wrote and delivered the 30-minute walkthrough of the reporting suite. Home page and navigation, KPI definitions, then the reports themselves: retailer performance, product performance, top sales insights, sales insights overview, campaign performance, basket composition, product mapping.
• •Taught the metric definitions properly rather than reading them off the screen. Leads are deduplicated unique clicks, not raw clicks. Conversion rate is baskets divided by leads, and sits against a vertical benchmark built from ChannelSight's own historical data. Brand revenue lock-in is brand revenue over total revenue, and it's how you tell which retailer is actually converting the brand's own products instead of pushing the shopper to something else on the shelf.
• •Explained the three retailer sales-data levels up front, because they decide which columns can even be populated. Basket level gives you transaction visibility with no itemised breakdown. Product level gives you the items too. No sales data means traffic only.
• •Covered filtering, secondary dimensions, date comparison, and how to get the data out. Crosstab in Excel format, section by section, because the tool exports per section.
• •Wrote the short guide for downloading and subscribing to Looker reports.

📈 Quarterly business reviews

• •Ran the full production process: data check on operations and retailers, performance review QA and data prep, export through the review Excel template, build the deck, review, edit, align with the customer success manager, present or send, follow up.
• •Mapped the time each stage actually took and set expectations against it. Seven to ten days for a normal client, fourteen for a new one, three for a low-traffic client where the output is closer to a set of interface recommendations than a data story.
• •Worked top-down: start with the headline growth rate across all brands and markets, then find the driver — a new market or retailer going live, growth in existing key accounts, or something external like seasonality or a year-end push.
• •Then compared growth rates against each other, because the gaps are where the story is. Brand revenue growing faster than leads → brand share of the basket went up (or average item value did). Leads growing faster than revenue → campaign traffic that isn't converting. Baskets growing faster than leads → conversion improved.
• •Treated sharp quarter-on-quarter drops as a diagnostic, not a result. First check whether a retailer stopped sending sales data. Then shoppability — retailers gone out of stock or a buy button that broke. Then year on year for seasonality. Raise a support ticket if it's a fault.
• •Looked at category contribution, price-band distribution, competitive sales share, and how much of a market's revenue rests on a handful of SKUs — heavy top-SKU concentration is a risk worth flagging to the brand.

🔍 Interface and setup audits

• •Scored how brands had implemented the buy button using a weighted scorecard: widget type (pop-up, in-line, or both), whether the widget shows stock and price, how many touchpoints beyond the product page, and product coverage across key retailers.
• •Each factor scored and weighted into a total, then converted into a percentage so brands could be compared and tracked over time.
• •The audits fed directly into the review decks. A brand sitting at 35% with a pop-up on the product page and nothing else has an obvious next move, and it's a cheaper fix than more media spend.
• •Flagged the trade-off honestly. More touchpoints generally means more clicks to retailers, but not without limit — too many can work against you.

🔗 Tracking setup and validation

• •Wrote the internal guide for dynamic tracking. A script on the brand's site reads UTM parameters off the landing URL, stores them in a cookie, then injects them into the widget's data attributes so the campaign that drove the click is still attached when the shopper reaches the retailer.
• •Set the boundary with clients: their developer implements it from our guide, we validate it. Validation meant testing in an incognito window, accepting cookie consent, clicking through the widget and inspecting the button attributes to confirm the parameters carried.
• •Documented the common failure modes so the team stopped rediscovering them: wrong parameter names, setup applied inconsistently across page types, and server cache serving the old version. Also the cookie consent question, since some brands only pass parameters on full consent and others accept partial.
• •Covered WTB source tracking separately — the touchpoint-level dimension, either injected in the page code or set per asset in the portal — which answers which blog post, which button placement, or which landing page variant is actually driving retailer clicks. Explained what a NULL value means so nobody read it as zero.

📡 Google Analytics integration

• •Wrote the client-facing guide and the meeting script for pushing ChannelSight sales events into the brand's own Google Analytics.
• •Covered the mechanics: enable dynamic subtag parameters per live asset in the portal, wait for validation, then daily automated exports through the Google API into the brand's property.
• •Covered what the client has to do on their side, which is the part that gets skipped. Custom dimensions have to be created in GA4 first, because Google can't tell brand from non-brand items or recognise retailer names on its own. The exports only get scheduled once those placeholders exist.
• •Explained the discrepancy in advance rather than after the complaint. GA depends on cookies, so a rejected cookie means the session can't be matched there even though the sale still shows in the ChannelSight dashboard.
• •Handled the pricing and scoping questions, including how the setup works for brands still on Universal Analytics, and what changes with multiple properties.

🧩 Product and sales data

• •Learned the data model well enough to explain it to clients and to debug it. Manufacturer product data on one side, retailer product data on the other, joined by product matching.
• •Product data arrives three ways: a recurring catalog upload from the brand, crawls of the retailer site, or a retailer data feed / API. Amazon gets both crawl and feed.
• •Sales matching runs through an ordered rule set: exact product code against the brand SKU, exact code against the mapped retailer code, ASIN or EAN, description starting with the brand name and containing the SKU, exact description against the mapped retailer product name, then brand identification from legal and variant names. Roughly nine in ten cases resolve through those rules. The rest are where false positives live — usually retailers whose SKU formats collide, or product names that don't separate variants.
• •If a sale matches, it counts as brand revenue. If it doesn't, it stays in total revenue. That single distinction drives most of the reporting brands care about, and most of the confusion.

Where to Buy Online · Where to Buy Local · Shoppable Media · Ratings and Reviews · Price and Inventory monitoring · Content Compliance · Search Placement.

Internal naming for these varies a lot, so I kept a glossary of official names, acronyms and internal synonyms to stop briefs getting misread.

Passed the internal product knowledge assessments between November 2022 and January 2023, covering widget behaviour, API and data feed rules, business rules, and what can and can't be changed by the client versus support.

6 Tracking Parameters for Full-Funnel Visibility

Implementation Expertise

• • Widget Integration: Configured JavaScript widgets with dynamic tracking parameters on brand websites
• • API Configuration: Implemented tracking parameters via ChannelSight API for custom integrations
• • Cookie Consent Management: GDPR-compliant session ID capture with user consent validation
• • Analytics Integration: Connected ChannelSight clicks to Google Analytics custom dimensions for unified reporting
• • Cross-Platform Attribution: Tracked user journeys from Facebook/Instagram ads → brand.com → retailer purchase