Work / Analytics application

Thailand AI Market Intelligence

EXPERIMENTAL

วัดการมองเห็นแบรนด์ โดยแยกคำตอบ AI ออกจากอันดับผลค้นหา

Source repository

Comparing visibility across providers is misleading when generative answers and search rankings are blended into one metric.

My implementation: Query generation, provider adapters, DuckDB storage, analytics modules and a FastAPI dashboard backend. Committed tests cover storage, engine behavior, analytics, API contracts and pipeline integration.

Public implementation with live-provider adapters and explicitly synthetic demo modes; production adoption is not established.

01

Context

A brand may appear in an AI recommendation, an organic search result, or a retrieved citation. Those observations answer different questions.

Problem

Comparing visibility across providers is misleading when generative answers and search rankings are blended into one metric.

What it enables

Makes each observation traceable to a provider, query and run, with separate metrics for generative answers and search results.

Constraints

  • Public implementation with live-provider adapters and explicitly synthetic demo modes; production adoption is not established.
  • The committed screenshot is labelled Serper: its search rankings are not evidence of generative-AI recommendations or market leadership.
02

System

A Python/FastAPI application that collects brand observations, stores their provenance in DuckDB, and compares results by answer surface.

Inputs

  • Configured brands and aliases
  • Thai consumer-intent queries and personas
  • Provider responses or deterministic mock observations

Implementation

  • Generate queries and route them through a provider adapter.
  • Persist observations, brand mentions and citations with run identifiers in DuckDB.
  • Reload persisted observations for surface-specific metrics, API responses and the web dashboard.
  • Query generation, provider adapters, DuckDB storage, analytics modules and a FastAPI dashboard backend.
  • Committed tests cover storage, engine behavior, analytics, API contracts and pipeline integration.
03

Decisions

  • Separate the answer surfacesA search-result position should not inflate a metric intended to describe generative recommendations.
  • Analyze the persisted recordReading back from the canonical store makes persistence failures visible and keeps API results traceable to a run.
  • Make synthetic mode explicitDeterministic mock observations help exercise the workflow but cannot support a business conclusion.
04

Artifacts

The artifact above is the committed evidence for this project. More screenshots and files are in the public repository.

05

Evidence

Evidence classes distinguish what can be inspected directly from what is documented, simulated or reconstructed.

06

Limitations

  • Live-key integration tests and production hardening remain gaps in the source status document.
  • Scan job state is in-process. Recommendations and the what-if simulator are not validated business-impact forecasts.
  • The screenshot's market-leadership wording exceeds what its small Serper sample establishes; the portfolio does not endorse that claim.

Discuss a system like this.

Start a work enquiryAll work