From market evidence to a reviewed decision

Choose your market and category

Sign in and open workspace setup. Choose the country and category offered for your market. If your category is missing, contact us to check its coverage. Store, ERP and customer-data connections are scoped separately with your team.

• Define the question: assortment, price, trend or competitor context.
• Select relevant public sources or a supported public store domain.
• Confirm source availability and coverage before relying on a report.

Read the evidence before the headline

A public listing describes what a source shows at a point in time. It does not establish sales, stock ownership or customer demand. Review the source, collection time, market, category and any missing coverage alongside the recommendation.

• Check whether an output is live evidence, a modelled example or a sandbox scenario.
• Treat a missing source or sparse coverage as a limit, not a zero value.
• Keep estimates separate from observed facts; verify important decisions against your own context.

Map each product to one category path

Choose the category tree your catalogue must follow, such as a marketplace or retailer taxonomy. A suggested path is drawn from the product title and description and shown with its supporting and missing evidence. A CSV export of titles and descriptions is enough to start. A suggested path stays a proposal until a reviewer accepts it.

• Choose the tree first; a category path only means something inside one tree.
• Review each suggested path with its evidence and any missing fields beside it.
• Check accuracy by category level on a labelled sample before a larger run.
• Keep the suggested category on the product record in your PIM, and approve it there before it goes live.
• One product can need a different category path for each channel; review each channel path separately.

Evidence → inbox → review → audit

The seven-stage workflow is organised around decisions. Where the workflow is available, route evidence to the receiving stage's inbox, review its constraints, then accept, override or revise with a reason. Preserve the provenance and decision record so a teammate can understand what changed.

• A recommendation remains a proposal for human review.
• An override should explain why the evidence or constraint was insufficient.
• Agree any changes to connected systems separately before enabling them.

Plan a connection with its owner

List the question, source system and minimum fields needed. Ask NOGL to confirm availability and a setup plan before granting access. A public catalog scan does not connect private orders, customers or stock quantities.

• Name the authorised account owner and agree read access; review any write access separately.
• Confirm permitted users, processing terms, retention and how access can be revoked.
• Validate a small authorised sample, its timestamps and missing records before a broader rollout.

Agree how you will measure the decision

Record a baseline before the pilot and choose a decision metric with your team. For example, compare the time needed to review a range with the same scope and evidence requirements. Commercial outcomes require your own reliable sales and cost data.

• Write down the metric, baseline period, data source and known gaps.
• Name a review owner and date, and record what else changed during the test.
• Compare outcomes with the agreed baseline; separate observations from estimates and do not attribute every change to NOGL.

Why a KPI moved, with its linked signals

When a KPI moves, group the related signals into one incident. Each card shows the segment, the size and length of the change, the contributing factors, the sources behind a drafted explanation and its confidence. The review step is shown as text: a person accepts, overrides or revises the draft with a reason, outside this page.

• Related anomalies sit in one incident with their contributing factors.
• Each incident shows the segment, the size and length of the change.
• An explanation is a draft until a person accepts it; its sources and confidence are shown with it.

Ranked anomaly insights, with a root-cause timeline

Find unusual changes without setting a threshold for each metric. Insights are ranked by estimated impact. Open one to see its timeline from the first failure to the current state, the services or segments affected and a suggested next step.

• Insights are ranked by estimated impact, with the largest first.
• Each insight opens a timeline from the first failure to the current state.
• A suggested next step is shown with its reason, for a person to decide outside this page.

Follow a competitor group with dated evidence

Read the keyword overlap, share trend and catalogue of a sample set of competitor listings side by side. Each figure keeps its source, collection date and coverage note, so an estimate is never read as a sale.

• Keyword overlap is shown for the listings in the example, with the search terms that lead shoppers to each one.
• A share trend is labelled as an estimate and names the period and the market it covers.

Check look-alikes before a range decision

Read a worked example of a look-alike check: a sample image gives near matches and comparable items that are in stock. Each match shows its basis and the image set searched, so a close match reads as a reason to review, not as proof of demand.

• The example names the image set it covers and the date it was last refreshed.
• Each match shows its basis, such as shape, colour, pattern or text, beside the similar item.

Match a photo to your own catalogue, with a category check

See how a shopper photo is compared with a catalogue, ranked by score, and checked for product category before a match is accepted. This block uses an illustrative catalogue extract and is not connected to any live catalogue.

• Show the rank, score, article number, price and stock for each match, labelled as sample data.
• Apply the category rule first, so a tea towel that looks like a scarf is shown as rejected rather than ranked.

Test a shopper query against the catalogue

Try a sample text query, a sample photo or both, and read the ranked products with the attributes that matched each one. The suggestions and products on this block are invented for illustration, so no live catalogue is searched.

• Show the matched attributes, such as object, pattern and colour, beside each result.
• Rank results on one scale and state what the score measures, so a reviewer can see why a product sits where it does.

See each product's readiness before it reaches a channel

Each product carries one record. A completeness score reflects the attributes its channels require, the missing fields are listed by name, and each channel shows when it last accepted the product and why any item was rejected. This block uses invented products and statuses only.

• Show a missing attribute as a named gap that lowers the score, never as zero or as a blank.
• Show, in one list, each channel's last accepted push and every rejected item with its reason.

See one catalogue item against three category taxonomies

Compare the category path one item receives in Google Shopping, Shopify and Amazon. Each path names the taxonomy version it comes from, so a path is never read without its tree. This block uses one invented item and labelled sample paths.

• Show the same item against each taxonomy side by side, with the path depth and the version label.
• Mark a path as a suggestion until a reviewer accepts it, and list any level that the item does not reach.

Find the missing required attributes on each product

Each product is checked against the attributes its sales channel requires. Missing fields are listed with a suggested value, and the completeness score is shown before and after the suggestion. A suggestion stays a proposal for review until someone accepts it. This block uses invented products only.

• Show the completeness score before and after each suggested value, so the change is visible.
• Keep a suggested value apart from the value already in the record, and mark its source.

Check each product against one channel's required fields

Map your catalogue attributes to the fields one sales channel needs, then check every product before it is exported. Each failing product is listed with the field and the reason. This block uses an invented catalogue and invented channel rules and sends nothing to any channel.

• Show which catalogue attribute feeds each required channel field, and flag the mandatory ones.
• List every failing product with the failing field and a plain reason, never as a silent pass.

Get help with coverage or setup

Send the market, category, public source URL and the step that needs attention. Include a report reference if available. Do not send passwords, API keys, customer exports or personal data through the general contact form.

• Ask us to confirm supported sources and the scope of your workspace.
• Agree data access, responsibilities and success criteria before a connected-data pilot.

Seven stages, one connected decision journey

Use this map to understand the wider NOGL workflow. The public-market workspace starts with market evidence; access to later stages and connected data depends on the scope agreed for your workspace. Confirm the stages and data sources included in your pilot with the NOGL team.

1. 1

   Market Sense

   Choose a market and category, then inspect public signals and their sources.

2. 2

   Design Studio

   Translate evidence into a product direction and check the assumptions behind it.

3. 3

   Source & Cost

   Review sourcing and cost assumptions before treating them as a buying decision.

4. 4

   Hero Products

   Compare product candidates, evidence and constraints before selecting a priority.

5. 5

   Price & Promote

   Review pricing and promotion proposals against the evidence available.

6. 6

   Customer Care

   Use authorised connected customer information where the agreed scope supports it.

7. 7

   Returns & Recovery

   Review returns evidence and feed the learning into the next product decision.