DEV Community: Enoch Chan

Google Preferred Sources: reader choice, not a ranking guarantee

Enoch Chan — Mon, 24 Aug 2026 09:41:16 +0000

Google Preferred Sources: reader choice, not a ranking guarantee

Google documents an interactive Preferred Sources button that can return readers to the page after they complete the selection flow. For publishers, the useful question is not how to promise a search outcome. It is where a reader who already values the publication can make a preference explicit and continue reading.

The safe message is simple: make the action easy to find, explain what the reader is confirming, and keep the experience tied to an existing trust moment such as the article end or publication information area. Do not turn that reader preference into a ranking, traffic, or eligibility guarantee.

A short implementation review can therefore follow three steps: choose, confirm, and return. The page should make the action understandable without imitating Google UI or inventing proof. The exact Google documentation remains the source for the feature details and eligibility boundaries.

Hydrogen pageviews: verify what client-side navigation actually emits

Enoch Chan — Sat, 22 Aug 2026 22:18:53 +0000

Hydrogen pageviews: verify what client-side navigation actually emits

Shopify's August 18, 2026 Hydrogen developer preview includes a specific observability change: every navigation now emits a page view. The safe takeaway is scoped. It is not a claim that every Shopify storefront was losing pageviews, and it is not a promise of better revenue attribution. It is a reason to test the Hydrogen version and analytics path you actually run.

The useful test

Start with one initial page load. Navigate through two client-side routes. Then inspect the events that arrived, including their route context and timestamps. Compare what your instrumentation recorded with the navigation sequence you performed.

Why the distinction matters

A single recorded pageview can hide what happened after the first load when a storefront behaves like an app. Treating the first load as the whole session can make a team reason from incomplete telemetry. The practical check is simple: load, navigate, verify.

Keep the result tied to the Hydrogen developer preview scope described by Shopify. If the event trail differs from the behaviour described in the preview, record the deployed version and investigate the analytics integration rather than generalising from one test.

Source: Shopify Hydrogen developer preview update: August 18, 2026.

From views to a feedback loop: a three-step rule for new accounts

Enoch Chan — Fri, 21 Aug 2026 07:17:31 +0000

Views are exposure, not a conversation

YouTube's official creator guidance makes a useful distinction: views do not automatically equal fans, and community is built through conversation rather than monologue. The exact Shorts features are platform-specific, so the transferable idea is a behaviour loop rather than a universal feature claim.

The loop

Ask one answerable question. Listen for repeated answers, objections or examples. Reply with the next useful post. That changes a one-way calendar into a feedback loop: POST → RESPONSE → NEXT POST.

The point is not manufactured comments or a guaranteed audience outcome. It is to make participation easy enough that a real response can shape what comes next. The source describes polls, quizzes, Q&A, Add Yours stickers and video replies as YouTube Shorts features; use those examples only on YouTube and adapt the underlying conversation mechanic carefully elsewhere.

A practical check

Before publishing, ask: what can someone answer in one sentence, what response would change the next post, and how will the reply visibly acknowledge that input? Those questions turn a broad audience-growth ambition into an observable editorial workflow.

Source: https://blog.youtube/creator-and-artist-stories/grow-youtube-channel-interactive-shorts/

Why integrations fail quietly

Enoch Chan — Wed, 19 Aug 2026 08:34:53 +0000

Why integrations fail quietly

An integration can be technically connected while still being operationally fragile. A request may time out, a downstream system may reject a value, or a retry may happen without anyone knowing what changed. The danger is not only the error. It is the silence around the error.

A useful first step is to map one real workflow from request to outcome. Name the system that owns each important field. Decide which failures are safe to retry and which need a human decision. Then log the handoff in a way that lets someone answer three questions: what happened, where did it stop, and what should happen next?

This is a small control loop, not a promise to connect every tool. Start with one flow, make the failure path visible, and only then add more automation.

Search Beyond Your Website

Enoch Chan — Mon, 17 Aug 2026 10:04:33 +0000

Search beyond your website

Social and video teams often judge a post through native reach, likes, comments or watch time. Google discovery is a separate evidence layer, and it can answer a different question: which posts and queries are earning attention from Google Search and Discover?

Google Search Console platform properties can show how Instagram, TikTok, X and YouTube content performs on Google Search and Discover. The reporting can also show which queries and posts drive Google discovery, including clicks and impressions.

That does not make Search Console a replacement for native analytics. Google discovery is not total in-platform reach or engagement, and discovery alone does not prove conversion. The useful workflow is to keep the two layers separate, then compare them before choosing the next topic or format.

A bounded review rule

Start with the native-platform signal your team already tracks.
Check the relevant Search Console platform property.
Compare the queries and posts earning Google discovery.
Choose the next experiment only after looking at both evidence layers.

This keeps a discovery signal from becoming an exaggerated reach claim. It also gives content operators a practical reason to review search data alongside their existing social workflow.

The source for the platform-property claim is Google Search Central.

Inventory Moved Buckets, Not Totals

Enoch Chan — Sun, 16 Aug 2026 19:19:08 +0000

Inventory moved buckets, not totals

Shopify says certain active holds from draft orders and transfer shipments are moving from reserved to committed. The available, on-hand and total inventory values remain unchanged in this migration.

That distinction matters in competitor research and operations reporting. A bucket label can move while the underlying inventory totals stay fixed. If a dashboard only shows the bucket delta, it is easy to escalate a reporting migration as though stock changed.

A bounded review rule

Timestamp the change — record when the bucket movement appeared.
Add platform context — note the Shopify change before interpreting the metric.
Check the totals — compare available, on-hand and total before calling it a real stock event.

This is a measurement and systems-design rule, not a claim that every reserved inventory movement is covered. The Shopify changelog is the source for the specific migration.

Can an EPOS Audit Trail Prove What Changed?

Enoch Chan — Sat, 15 Aug 2026 22:05:28 +0000

Can an EPOS audit trail prove what changed?

HMRC is consulting on proposed EPOS/MPOS software standards until 18 August 2026. The proposed package includes an unalterable and complete transaction log with individual transactions and adjustments indelibly linked in an encrypted chain. These are consultation-stage proposals, not current final standards.

The practical engineering question is broader than the policy context: when a sale changes, does the system preserve the original state, record the adjustment explicitly and keep the relationship between both states traceable? A final value by itself may be easy to read, but it does not necessarily explain what changed or how a reviewer can reconstruct the path.

A simple review rule

Use three visible states:

Original — retain the first recorded transaction.
Adjustment — represent the correction as a distinct event.
Linked history — preserve the relationship so the change can be followed later.

This is an audit-trail design test, not tax advice and not a claim that the consultation proposals are already mandatory. The HM Revenue & Customs consultation is the source for the policy context; the implementation process and timeline have not yet been decided.

How to Read a Competitor Review-Count Change

Enoch Chan — Fri, 14 Aug 2026 09:55:43 +0000

How to read a competitor review-count change

A competitor app review count can move while the cause remains uncertain. Treat the movement as an observed delta, not as automatic proof that customer demand changed.

Shopify said on 6 July 2026 that expanded authenticity signals apply to existing and new App Store reviews, and reviews that do not meet its authenticity bar will be unpublished gradually during the backfill. That platform context matters when a team compares counts across dates.

A bounded monitoring rule

Timestamp the count and preserve the before/after observation.
Annotate known platform-policy or moderation context.
Keep the conclusion narrow: the count changed; the cause still needs evidence.

This approach avoids turning a useful competitive signal into an unsupported demand story. Pair the count with other evidence before making a product or market decision.

When an empty Shopify result is a broken filter

Enoch Chan — Thu, 13 Aug 2026 09:46:02 +0000

When an empty Shopify result is a broken filter

An empty API result is not automatically proof that there is no data. The filter itself may be invalid, and a silent response can make that failure look like a business fact.

The 2026-10 change

Shopify’s official changelog says that, starting in API version 2026-10, invalid metafield filters return an explanatory error instead of silently returning misleading results. The release is scheduled for 1 October 2026; 2026-07 and earlier retain previous behaviour until upgrade.

Three checks before trusting an empty result

First, confirm that the metafield has a definition. Second, confirm that filtering is enabled for it. Third, confirm that the comparison is supported. A valid filter using a supported comparison behaves as before; the point is to distinguish a valid empty result from an invalid query.

A practical migration rule

Inventory metafield-filter queries before upgrading, test each one against the target version, and treat an explanatory error as a query defect rather than “no data”. That small check keeps a silent filter problem from becoming an unverified product or reporting assumption.

Source: Shopify — Invalid metafield queries now return errors in the GraphQL Admin API

Which suppliers need Cyber Essentials?

Enoch Chan — Wed, 12 Aug 2026 08:45:54 +0000

Which suppliers need Cyber Essentials?

The voluntary UK Cyber Resilience Pledge gives signatories a useful supplier-assurance rule: audit Cyber Essentials coverage across the supply chain, then use supplier risk to decide where certification is required. It is not a universal legal duty and it does not say every supplier must hold Cyber Essentials.

Start with coverage

First, establish which suppliers already hold Cyber Essentials and where coverage is absent or unclear. A coverage audit turns a vague policy discussion into a visible supplier list that can be reviewed by the people responsible for risk.

Assess supplier risk

The declaration calls for a risk-based approach. That means the requirement should follow the supplier's role, access, dependency and potential impact rather than one blanket checklist. The public guidance does not prescribe one scoring model, so organisations still need to define their own risk appetite and decision ownership.

Choose the assurance path

Where risk justifies it, require Cyber Essentials. Where certification is not required, the declaration says the exception should align with organisational risk appetite and strategy, and adequate assurance should be obtained through other means. Record the reason, the alternative evidence and the reviewer.

A reusable workflow is: coverage → risk → requirement → evidence. Keep each supplier decision tied to the evidence that supports it, and revisit the decision when the supplier's access, service or risk changes.

Sources:

Why a live payment is not a release test

Enoch Chan — Tue, 11 Aug 2026 09:35:41 +0000

Why a live payment is not a release test

The riskiest way to test a SaaS checkout is to make a real payment to yourself. It feels reassuring: the live checkout opened, the card worked, the webhook fired and the refund came back. But that proof mixes engineering QA with revenue evidence.

Three different proofs

A cleaner billing release process separates three questions:

Does billing behave correctly? Test payment, refund, webhook and subscription edge cases in a Stripe sandbox.
Is production configured correctly? Verify the live price, currency, checkout destination, webhook configuration and deployed revision without moving money.
Did a customer pay? Treat a genuine live transaction as customer activity and revenue evidence, not as an engineering fixture.

Stripe documents sandboxes as isolated testing environments and separates sandbox credentials from live credentials. The practical lesson is broader than Stripe: operational proof and commercial proof should not share the same transaction.

A useful boundary

Use this sequence: Sandbox QA → read-only production verification → genuine customer payment. It keeps release evidence, reconciliation and revenue numbers easier to interpret.

We recently tightened the same boundary in VendorOS. That does not prove live customer revenue; it is a workflow lesson about keeping evidence categories separate.

If your release process still requires a live self-payment, ask which part of the verification can become read-only.

Sources:

A Five-Part Evidence Check for ICT Supplier Due Diligence

Enoch Chan — Mon, 10 Aug 2026 11:25:09 +0000

Supplier questionnaires are useful, but completion is not the same as due diligence.

NIST SP 1326, finalised on 8 July 2026, defines five Due Diligence Assessment components for ICT suppliers: Foreign Ownership, Control, or Influence (FOCI); Provenance; Resilience; Foundational Cyber Practices; and Supply Chain Tiers.

Turn each component into an evidence test. For FOCI, record the relevant evidence and any uncertainty. For provenance, record the evidence available about origin. For resilience, capture the evidence the review relies on. For foundational cyber practices, record concrete supporting material. For supply-chain tiers, identify the evidence available about relevant upstream dependencies.

Before approval, a practical internal rule is to record one of three things for each component: an evidence note, an explicit gap, or a named risk acceptance. That creates a clearer decision record than treating questionnaire completion as the end of the review.

SP 1326 is NIST guidance scoped to ICT supplier due diligence. It should not be presented as a universal legal requirement.

VendorOS can be used as evidence-workflow context for questionnaire review and explicit approval. The five-part framework itself comes from NIST.