Work / Analytics application
Thailand AI Market Intelligence
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.
Source screenshot: Serper search observations. Its market-leadership wording is not a verified outcome, and this is not a live portfolio dashboard.
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.
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.
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.
Artifacts
The artifact above is the committed evidence for this project. More screenshots and files are in the public repository.
Evidence
Evidence classes distinguish what can be inspected directly from what is documented, simulated or reconstructed.
- VERIFIED CODECollection, persistence and analytics orchestration
src/runner.py
- VERIFIED CODEDuckDB schema and observation storage
src/storage/duckdb_store.py
- VERIFIED TESTCommitted pipeline integration tests
tests/test_pipeline_integration.py
Source inspection; the portfolio audit did not execute paid-provider calls.
- VERIFIED ARTIFACTCommitted Serper dashboard capture
docs/assets/dashboard.png
- README REPORTEDFeature status and remaining gaps
docs/STATUS.md
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.