System Requirements Document for marketplace-digital-marketing

1. Introduction

SEVPP ANALISIS — Economic Research & Investment Insight is a professional digital market intelligence website that connects to actual, verifiable data sources in order to monitor marketplaces, consumer trends, product performance, competitors, and digital marketing activity.

The product's intent is forensic rather than promotional: it exists so that an operator can look at a market figure and know exactly where that figure came from, when it was retrieved, and over what measurement period it was measured. Every capability in this document is subordinate to that intent.

The audience is Indonesian market-facing operators: analysts who read marketplace and search data daily, the administrators who own the platform integrations and credentials behind that data, and the business decision makers who act on the resulting analysis.

Absolute conditions carried from the source:

• Simulated data or fabricated figures are prohibited.
• Displaying data that has no clear source is prohibited.
• Claiming real-time data when the source does not support real-time updates is prohibited.
• Fabricating sales counts, revenue, demand, or competitor performance is prohibited.
• When data is unavailable or an integration is disconnected, the actual data status must be displayed.
• Every figure must be traceable to its source, retrieval time, and measurement period.

2. System Overview

SEVPP ANALISIS is delivered as a first-party web application with application-owned identity, a persistent backend, a scheduled synchronization engine, and a verified-data layer that sits between raw source retrieval and everything the user sees.

Current delivery shape:

• A public entry surface that states the product's purpose and shows the real, current state of its registered sources.
• Application-owned identity with self-service first-use enrollment and returning verification.
• A protected intelligence workspace: market dashboard, interactive charts, AI market analyst reports, and market opportunity scoring.
• A protected integration administration workspace: source monitoring, integration setup and authorization, and the audit log.
• A protected data quality surface for validation, completeness, freshness, unusual-change, and cross-source discrepancy review.
• Background automation: scheduled synchronization, webhook intake where a platform provides it, retry on failure, validation, duplicate detection, and update-history storage.

Actors: three accepted human personas (Market Intelligence Analyst, Data Source & Integration Administrator, Business Strategy Decision Maker) plus typed non-persona actors — the official platform APIs and authorized business accounts (Shopee, Tokopedia, Lazada, TikTok Shop, Google Trends, Google Analytics, Google Search Console, Meta Ads Library, and other officially accessible marketing analytics platforms), and the internal synchronization and validation processes.

Narrow exclusions: no simulated or illustrative figures anywhere in the product; no invented chart history; no merging of figures whose definitions or periods differ; no API keys in frontend code; no bypassing of authentication, access restrictions, or platform terms of use; no claim of successful integration before connection testing and data validation complete.

2a. Product Interpretation and Delivery Boundary

SEVPP ANALISIS is a first-party application that owns its own identity, its own database of synchronized records, and its own verification layer. It does not own the market data itself: Shopee, Tokopedia, Lazada, TikTok Shop, Google Trends, Google Analytics, Google Search Console, Meta Ads Library, and any other officially accessible analytics platform remain the owners of their data and of the authorization that grants access to it. SEVPP ANALISIS retrieves that data only through official APIs, authorized business accounts, or licensed third-party providers with the right to supply it, and it presents the data together with the source, retrieval time, and measurement period that make it traceable.

Access to the product is application-owned. A first-time user enrolls through self-service; a returning user verifies identity through login. Protected market intelligence, integration administration, and audit surfaces are reachable only after identity is established. The public entry surface is anonymously reachable and carries no protected state.

The boundary between current and future work is explicit. Current work is the functioning integration, synchronization, verification, dashboard, chart, AI analysis, opportunity scoring, source monitoring, and audit capability described in this document. Anything not stated in the authoritative requirements — additional marketplaces beyond those named, additional analytics platforms beyond those with official access, or any capability that would require inventing data to demonstrate — is out of current scope. Where a platform does not expose a public API for a given data type, that data type is simply not synchronized from that platform, and the product says so rather than filling the gap.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source; all product facts derive from the authoritative user requirement thread and the accepted Planning Scope.

2c. Page Content and Component Coverage

Landing

• Information and state: the product wordmark SEVPP ANALISIS, a one-line statement of the product's actual current state generated from real integration status (registered source count, verified count, last update time), and a nine-row live source panel showing each registered platform with its real status.
• Primary actions: proceed to Sign Up (first-time enrollment); proceed to Login (returning verification).
• Supporting actions: read the source panel rows to see which integrations are VERIFIED, STALE, ERROR, or ACCESS REQUIRED before entering.
• Domain entities: registered data source, integration status (CONNECTED, SYNCING, VERIFIED, STALE, ERROR, ACCESS REQUIRED), last synchronization time, record count.
• Component responsibilities: masthead with wordmark and status line; nine-row source panel where each row is a hairline-ruled label/value pair with a status LED and the spelled-out status word; a full-width verification ledger band listing source → records processed → retrieval time.
• States: loading — source panel rows render in a neutral unresolved state until status is fetched; empty — if no sources are registered, the panel states that no sources are registered rather than showing placeholder rows; success — each row shows its real status and last-sync time; error — if status cannot be fetched, the panel states that status is unavailable and does not substitute a value; recovery — the panel retries status retrieval and reflects the result.

Login

• Information and state: returning verification form for all authenticated product users.
• Primary actions: submit credentials to establish a session.
• Supporting actions: navigate to Sign Up if the user has no account.
• Domain entities: user identity, session.
• Component responsibilities: credential form; error region; link to Sign Up.
• States: loading — submission in progress; empty — initial form; success — session established and the user is returned to the protected destination they were seeking; error — invalid credentials are stated plainly with no account-existence disclosure; recovery — the user may correct and resubmit.

Sign Up

• Information and state: self-service first-use enrollment form.
• Primary actions: create an account and establish the user's identity in the product.
• Supporting actions: navigate to Login if the user already has an account.
• Domain entities: user identity, role assignment.
• Component responsibilities: enrollment form; validation region; link to Login.
• States: loading — submission in progress; empty — initial form; success — identity established and the user proceeds to the protected workspace; error — validation or enrollment failure is stated plainly; recovery — the user may correct and resubmit.

Dashboard

• Information and state: the professional market dashboard with red, black, and white dominance, summarizing total products successfully monitored, number of categories analyzed, highest-growth category, highest-selling products where data is available, products with the highest popularity increase, product price changes, consumer search trends, number of active integrations, and last synchronization time. All metrics are computed from genuinely available data only.
• Primary actions: apply filters by platform, category, period, price, product, and region where the source supports them; read each metric with its source chip and measurement period.
• Supporting actions: open a metric's underlying chart or record; navigate to Charts, AI Reports, Opportunity Scores, Data Quality, Integrations, or Audit Log.
• Domain entities: monitored product, category, price record, sales record, search trend record, integration, synchronization event.
• Component responsibilities: six metric tiles in a 3×2 block, each a gauge or tabular numeral with source chip and measurement period printed beneath; a single horizontal filter control bar that never collapses into a hidden drawer; a 2/3 + 1/3 split of a primary chart beside a source-and-freshness column.
• States: loading — tiles and chart render in an unresolved state until data is fetched; empty — a tile with no available data states the reason (no source, no records, insufficient history) instead of showing a zero or a curve; success — each tile shows its figure with source, retrieval time, and period; error — a failed fetch leaves the tile in an explicit unavailable state with no substitute figure; recovery — the tile retries and reflects the real result.

Integrations

• Information and state: the source-monitoring workspace showing, for each platform, platform name, connection status, available data types, last synchronization time, update frequency, successfully processed record count, failed record count, error notes, authorization status, and synchronization history.
• Primary actions: inspect a source's status and history; open Integration Setup for a source that requires authorization or configuration.
• Supporting actions: read error notes; review sync history entries; navigate to Audit Log.
• Domain entities: data source, connection status, authorization status, synchronization run, processed record count, failed record count, error note.
• Component responsibilities: per-source rows with status LED and spelled-out status word; a detail region for the selected source showing data types, frequency, counts, and error notes; a synchronization history list.
• States: loading — source rows render unresolved until status is fetched; empty — if no sources are registered, the workspace states that no sources are registered; success — each source shows its real status, counts, and history; error — a source in ERROR shows its error note and no substitute counts; recovery — the workspace reflects retry outcomes and updated history.

Integration Setup

• Information and state: the focused workspace for connecting and authorizing an official source and managing its secure integration configuration, including credential entry and connection testing.
• Primary actions: enter or update credentials for a source; run a connection test; save the configuration; authorize the source.
• Supporting actions: view the source's current authorization status; return to Integrations.
• Domain entities: data source, credential, authorization grant, connection test result, configuration.
• Component responsibilities: source selection; credential form with secure handling; connection test control and result region; save and authorize controls.
• States: loading — test or save in progress; empty — no configuration yet for the selected source; success — the source is presented as connected only after connection testing and data validation complete; error — a failed test or save is stated with its cause and the source is not presented as successful; recovery — the administrator may correct credentials and retest.

Data Quality

• Information and state: the review surface for validation status, completeness status, freshness status, unusual changes, and conflicting source values. Each record carries source name, source ID where available, retrieval time, source update time where available, data period, validation status, completeness status, freshness status, and limitation notes.
• Primary actions: inspect a record's verification metadata; inspect a detected discrepancy between two sources, shown as two figures side by side with the delta and both measurement periods between them.
• Supporting actions: filter records by validation, completeness, or freshness status; navigate to Audit Log for the corresponding events.
• Domain entities: data record, source, validation status, completeness status, freshness status, limitation note, discrepancy.
• Component responsibilities: record list with status columns; record detail region showing all required metadata fields; discrepancy block that never averages the two figures into one.
• States: loading — record list renders unresolved until fetched; empty — if no records exist, the surface states that no records have been synchronized; success — records show their real validation, completeness, and freshness status; error — a failed fetch is stated plainly; recovery — the surface reflects the real result on retry.

Charts

• Information and state: interactive charts reading directly from the synchronized database — Market Trend Chart (line, consumer interest over time), Product Sales Chart (historical sales from genuinely available transaction data), Category Performance Chart (bar comparison on the same metric), Price Movement Chart (price changes and cross-seller price comparison), Competitor Comparison Chart (price, rating, reviews, and other genuinely available metrics), Marketing Performance Chart (impressions, clicks, CTR, conversion, CPC, CPA, ROAS from authorized marketing accounts), and Market Opportunity Chart (relationship between demand growth, competition level, price, and margin potential where cost data is available).
• Primary actions: select a chart; apply a period filter; hover for tooltips; read the chart's source attribution.
• Supporting actions: read the caption row beneath each chart carrying source name, retrieval timestamp, and measurement period.
• Domain entities: chart series, data point, source, measurement period, filter selection.
• Component responsibilities: chart panel with plot area; caption row; period filter control; tooltip; clear axis labels; source attribution.
• States: loading — the chart panel renders unresolved until data is fetched; empty — when historical data is insufficient, the chart states the reason and shows no curve, never a fabricated history; success — the chart draws from actual database records with tooltips, labels, and source; error — a failed fetch leaves the panel in an explicit unavailable state; recovery — the panel retries and reflects the real result.

AI Reports

• Information and state: traceable AI market analyst reports covering current market conditions, highest-selling products based on available data, highest-growth categories, products starting to gain attention, consumer interest changes, competitor analysis, business opportunities, market risks, digital marketing strategy recommendations, and the supporting data sources for each conclusion. Reports state uncertainty when evidence is insufficient.
• Primary actions: request or open a report; read each section with its cited supporting data sources.
• Supporting actions: follow a cited source to its underlying record or chart; navigate to Opportunity Scores.
• Domain entities: report, report section, conclusion, cited data source, uncertainty statement.
• Component responsibilities: report list; report body with the ten required sections; citation region per conclusion; uncertainty indicator.
• States: loading — report generation in progress; empty — if available data is insufficient for a section, the section states that evidence is insufficient rather than omitting or inventing it; success — the report presents conclusions with cited sources; error — a failed generation is stated plainly with no partial fabricated content; recovery — the user may request the report again.

Opportunity Scores

• Information and state: market opportunity scoring workspace showing scores built from sales growth where available, search interest growth, trend consistency, competition level, price changes, margin potential based on known costs, data completeness, and demand change risk. Each score explains its indicators and calculation method. Popularity is never presented as proof of profitability.
• Primary actions: open a score; read its indicator breakdown and calculation method; read its data completeness and uncertainty.
• Supporting actions: navigate to the underlying chart or record for an indicator; navigate to AI Reports.
• Domain entities: opportunity score, indicator, calculation method, data completeness, uncertainty statement.
• Component responsibilities: score list; score detail with indicator breakdown; calculation-method explanation; completeness and uncertainty region.
• States: loading — scores render unresolved until computed; empty — if an indicator's data is unavailable, the indicator states that it is unavailable rather than scoring it as zero; success — the score shows its indicators, method, and completeness; error — a failed computation is stated plainly; recovery — the workspace reflects the real result on retry.

Audit Log

• Information and state: the chronological record of when data entered, was processed, was updated, or failed validation.
• Primary actions: inspect audit entries; filter by event type, source, or time.
• Supporting actions: navigate to Integrations or Data Quality for the corresponding source or record.
• Domain entities: audit event, event type, source, timestamp, validation outcome.
• Component responsibilities: chronological event list; filter controls; event detail region.
• States: loading — event list renders unresolved until fetched; empty — if no events exist, the log states that no events have been recorded; success — events show their real type, source, and timestamp; error — a failed fetch is stated plainly; recovery — the log reflects the real result on retry.

3. Functional Requirements

Each requirement below is a distinct story point with its provenance, lifecycle facts, and observable acceptance.

FR-01 — Verified-source market intelligence platform (explicit) As a Market Intelligence Analyst, I should use SEVPP ANALISIS as a professional digital market intelligence website connected to actual data sources, so that I can monitor marketplaces, consumer trends, product performance, competitors, and digital marketing from one place.

• Trigger/input: the analyst opens the product.
• Observable result: the product presents market intelligence derived only from official APIs, authorized integrations, or verifiable public sources.
• Access state: protected workspace after identity is established.
• Failure/recovery: if a source is unavailable, the product shows the actual data status rather than a substitute.
• Continuation: the analyst proceeds to the dashboard, charts, reports, or scores.

FR-02 — Prohibition on simulated or unsourced data (explicit) As a Market Intelligence Analyst, I should never see simulated data, fabricated figures, or data without a clear source, so that every figure I read can be trusted as a measurement.

• Trigger/input: any data presentation in the product.
• Observable result: every displayed figure carries a source, retrieval time, and measurement period; no figure appears without them.
• Access state: applies to all surfaces.
• Failure/recovery: if a figure cannot be attributed, it is not displayed.
• Continuation: the analyst proceeds with attributable figures only.

FR-03 — Honest real-time claims (explicit) As a Market Intelligence Analyst, I should see real-time claims only where the source actually supports real-time updates, so that I am never misled about how current a figure is.

• Trigger/input: any freshness or currency label in the product.
• Observable result: freshness labels reflect the source's actual update capability and the record's actual freshness status.
• Access state: applies to all surfaces.
• Failure/recovery: where a source does not support real-time updates, the product does not claim it does.
• Continuation: the analyst reads the actual freshness status.

FR-04 — No fabricated sales, revenue, demand, or competitor performance (explicit) As a Market Intelligence Analyst, I should never see fabricated sales counts, revenue, demand, or competitor performance, so that competitive and commercial conclusions rest on real measurements.

• Trigger/input: any sales, revenue, demand, or competitor metric.
• Observable result: such metrics appear only where genuinely available data supports them; otherwise the metric states its unavailability.
• Access state: applies to all surfaces.
• Failure/recovery: unavailable metrics are shown as unavailable, not estimated.
• Continuation: the analyst proceeds with available metrics.

FR-05 — Actual data status on unavailability or disconnection (explicit) As a Market Intelligence Analyst, I should see the actual data status when data is unavailable or an integration is disconnected, so that I understand what is missing and why.

• Trigger/input: a source becomes unavailable or an integration disconnects.
• Observable result: the affected surface shows the real status (for example STALE, ERROR, or ACCESS REQUIRED) with no substitute figure.
• Access state: applies to all surfaces.
• Failure/recovery: the status itself is the recovery signal; the product retries where retry is defined.
• Continuation: the analyst continues with the remaining verified data.

FR-06 — Traceability of every figure (explicit) As a Market Intelligence Analyst, I should be able to trace every figure to its source, retrieval time, and measurement period, so that I can defend any number I act on.

• Trigger/input: the analyst inspects a figure.
• Observable result: the figure's source name, retrieval time, and measurement period are visible.
• Access state: protected workspace.
• Failure/recovery: if traceability metadata is missing, the figure is not presented as verified.
• Continuation: the analyst follows the trace to the underlying record.

FR-07 — Official source integration (explicit) As a Data Source & Integration Administrator, I should connect SEVPP ANALISIS to official data sources including Shopee, Tokopedia, Lazada, TikTok Shop, Google Trends, Google Analytics, Google Search Console, Meta Ads Library, and other marketing analytics platforms providing official access, using official APIs, authorized business accounts, or licensed third-party data providers, so that the product's intelligence rests on legitimate access.

• Trigger/input: the administrator selects a source and supplies authorized credentials.
• Observable result: the source is registered and its authorization status is recorded.
• Access state: role-restricted integration administration.
• Failure/recovery: a source that cannot be authorized remains in ACCESS REQUIRED and is not presented as connected.
• Continuation: the administrator proceeds to connection testing.

FR-08 — No assumption of universal public APIs; public/private separation (explicit) As a Data Source & Integration Administrator, I should have the product treat each platform's available data types according to what that platform actually exposes, and separate public data from private data available only through seller or advertiser accounts, so that the product never implies access it does not have.

• Trigger/input: the administrator configures a source.
• Observable result: the source's available data types are recorded and displayed; public and private data are distinguished.
• Access state: role-restricted integration administration.
• Failure/recovery: data types the platform does not expose are shown as unavailable rather than assumed.
• Continuation: the administrator proceeds with the data types that are actually available.

FR-09 — Synchronization of available data fields (explicit) As a Data Source & Integration Administrator, I should have the system synchronize, where available, product name and category, latest price, sales count, sales count change, rating and review count, product search position, promotion information, historical data, search trends, and marketing campaign performance, so that the intelligence layer has the fields the product promises.

• Trigger/input: a scheduled or webhook-triggered synchronization run.
• Observable result: available fields are retrieved and stored; unavailable fields are recorded as unavailable.
• Access state: background automation under administrator configuration.
• Failure/recovery: a field that cannot be retrieved is not fabricated.
• Continuation: the run completes and its history is recorded.

FR-10 — Real-time synchronization engine (explicit) As a Data Source & Integration Administrator, I should have an automatic synchronization engine that retrieves data through official APIs, schedules synchronization, accepts platform webhooks where provided, updates automatically within API limits, validates format and consistency, detects duplicates, handles synchronization failures, retries on connection failure, stores update history, and monitors per-source connection status, so that the data behind the product stays current and its history stays auditable.

• Trigger/input: schedule, webhook, or administrator-initiated run.
• Observable result: records are retrieved, validated, deduplicated, stored, and the run is recorded in history.
• Access state: background automation; administrator-visible status.
• Failure/recovery: failed runs are retried and their failures recorded.
• Continuation: the next scheduled run proceeds.

FR-11 — Per-integration status display (explicit) As a Data Source & Integration Administrator, I should see each integration's status as CONNECTED, SYNCING, VERIFIED, STALE, ERROR, or ACCESS REQUIRED, so that I know the real state of every source.

• Trigger/input: the administrator opens Integrations.
• Observable result: each source shows its current status with the status word spelled out.
• Access state: role-restricted integration administration.
• Failure/recovery: a source in ERROR shows its error note.
• Continuation: the administrator acts on the status.

FR-12 — Connection status is not completeness (explicit) As a Data Source & Integration Administrator, I should never see a successful connection status presented as a guarantee that all data is complete, so that I do not over-trust a connected source.

• Trigger/input: any status presentation.
• Observable result: connection status and completeness status are presented as distinct facts.
• Access state: applies to all surfaces.
• Failure/recovery: incomplete data is shown as incomplete even when the connection is healthy.
• Continuation: the administrator reviews completeness separately.

FR-13 — Verified data layer before display (explicit) As a Market Intelligence Analyst, I should have a verification layer applied before data reaches the dashboard, so that what I see has already passed the checks the product defines.

• Trigger/input: records arrive from synchronization.
• Observable result: records carry source name, source ID where available, retrieval time, source update time where available, data period, validation status, completeness status, freshness status, and limitation notes before display.
• Access state: applies to all data surfaces.
• Failure/recovery: records failing validation are not presented as verified.
• Continuation: verified records proceed to the dashboard, charts, reports, and scores.

FR-14 — Consistency, format, duplication, and unusual-change checks (explicit) As a Market Intelligence Analyst, I should have the system check value consistency, format, duplication, and unusual changes, so that anomalies are caught before they reach my analysis.

• Trigger/input: records enter the verification layer.
• Observable result: check outcomes are recorded as validation status and surfaced in Data Quality.
• Access state: protected workspace.
• Failure/recovery: a record failing a check is flagged rather than silently accepted.
• Continuation: the analyst reviews flagged records.

FR-15 — Cross-source discrepancy display (explicit) As a Market Intelligence Analyst, I should see the difference when two sources disagree, and the product should not merge figures whose definitions or periods differ, so that I can judge the disagreement myself.

• Trigger/input: two sources supply values for the same measurement.
• Observable result: both figures are shown side by side with the delta and both measurement periods; they are never averaged into one.
• Access state: protected workspace.
• Failure/recovery: if the discrepancy cannot be resolved, both figures remain visible.
• Continuation: the analyst decides which figure to use.

FR-16 — Professional market dashboard (explicit) As a Market Intelligence Analyst, I should have a premium market dashboard with red, black, and white dominance summarizing total products successfully monitored, number of categories analyzed, highest-growth category, highest-selling products where data is available, products with the highest popularity increase, product price changes, consumer search trends, number of active integrations, and last synchronization time, so that I get an immediate read on the market.

• Trigger/input: the analyst opens Dashboard.
• Observable result: each metric is computed from genuinely available data and carries its source and period.
• Access state: role-restricted protected workspace.
• Failure/recovery: a metric without available data states the reason instead of showing a value.
• Continuation: the analyst drills into a metric.

FR-17 — Dashboard filters (explicit) As a Market Intelligence Analyst, I should filter by platform, category, period, price, product, and region where the source supports it, so that I can narrow the market view to what I am investigating.

• Trigger/input: the analyst sets filter values.
• Observable result: metrics and charts reflect the filter selection; unsupported filters are shown as unsupported.
• Access state: role-restricted protected workspace.
• Failure/recovery: a filter the source does not support is not silently applied.
• Continuation: the analyst reads the filtered result.

FR-18 — Interactive charts from the synchronized database (explicit) As a Market Intelligence Analyst, I should use interactive charts that read directly from the synchronized database — Market Trend Chart, Product Sales Chart, Category Performance Chart, Price Movement Chart, Competitor Comparison Chart, Marketing Performance Chart, and Market Opportunity Chart — so that I can see market movement visually.

• Trigger/input: the analyst opens Charts and selects a chart.
• Observable result: the chart draws from actual database records.
• Access state: role-restricted protected workspace.
• Failure/recovery: a chart whose data cannot be fetched shows an explicit unavailable state.
• Continuation: the analyst applies a period filter or reads the source attribution.

FR-19 — Chart tooltips, filters, labels, and sources (explicit) As a Market Intelligence Analyst, I should have every chart carry tooltips, period filters, clear labels, and its data source, so that I can read and cite the chart correctly.

• Trigger/input: the analyst interacts with a chart.
• Observable result: tooltips, period filter, labels, and source attribution are present.
• Access state: role-restricted protected workspace.
• Failure/recovery: a chart missing source attribution is not presented as verified.
• Continuation: the analyst cites the chart.

FR-20 — No fabricated chart history (explicit) As a Market Intelligence Analyst, I should never see fake history created to fill a chart when historical data is insufficient, so that the shape of a curve always means something real.

• Trigger/input: a chart has insufficient historical data.
• Observable result: the chart states the insufficiency and shows no fabricated curve.
• Access state: role-restricted protected workspace.
• Failure/recovery: the empty state explains the reason.
• Continuation: the analyst waits for sufficient history or reads the stated reason.

FR-21 — AI market analyst reports (explicit) As a Market Intelligence Analyst, I should have AI analyze the synchronized data and produce reports covering current market conditions, highest-selling products based on available data, highest-growth categories, products starting to gain attention, consumer interest changes, competitor analysis, business opportunities, market risks, digital marketing strategy recommendations, and supporting data sources for conclusions, so that I get an analytical read on the market.

• Trigger/input: the analyst requests or opens a report.
• Observable result: the report presents all ten required sections with cited supporting data sources.
• Access state: role-restricted protected workspace.
• Failure/recovery: a failed generation is stated plainly with no fabricated content.
• Continuation: the analyst follows a citation to its underlying record.

FR-22 — AI uses only available data and states uncertainty (explicit) As a Market Intelligence Analyst, I should have the AI use only genuinely available data and state uncertainty when evidence is insufficient, so that I never mistake an inference for a measurement.

• Trigger/input: the AI generates a report or section.
• Observable result: conclusions cite available data; insufficient evidence is stated as uncertainty.
• Access state: role-restricted protected workspace.
• Failure/recovery: where evidence is insufficient, the report says so rather than concluding.
• Continuation: the analyst weighs the stated uncertainty.

FR-23 — Market opportunity scoring (explicit) As a Business Strategy Decision Maker, I should have a market opportunity scoring system built from sales growth where available, search interest growth, trend consistency, competition level, price changes, margin potential based on known costs, data completeness, and demand change risk, with each score explaining its indicators and calculation method, so that I can compare opportunities on a stated basis.

• Trigger/input: the decision maker opens Opportunity Scores.
• Observable result: each score shows its indicator breakdown and calculation method.
• Access state: role-restricted protected workspace.
• Failure/recovery: an indicator without available data is shown as unavailable rather than scored as zero.
• Continuation: the decision maker compares scores.

FR-24 — Popularity is not profitability (explicit) As a Business Strategy Decision Maker, I should never see popularity presented as proof of profitability, so that I do not mistake high demand for good margin.

• Trigger/input: any score or report presenting demand or popularity.
• Observable result: popularity and margin potential are presented as distinct indicators; margin potential is stated only where cost data is known.
• Access state: role-restricted protected workspace.
• Failure/recovery: where cost data is unknown, margin potential is stated as unavailable.
• Continuation: the decision maker weighs demand against margin separately.

FR-25 — Dedicated data source monitoring page (explicit) As a Data Source & Integration Administrator, I should have a dedicated page to monitor all data sources showing platform name, connection status, available data types, last synchronization time, update frequency, successfully processed record count, failed record count, error notes, authorization status, and synchronization history, so that I can operate every integration from one place.

• Trigger/input: the administrator opens Integrations.
• Observable result: every listed field is present per source.
• Access state: role-restricted integration administration.
• Failure/recovery: a source in ERROR shows its error note and no substitute counts.
• Continuation: the administrator opens Integration Setup or Audit Log.

FR-26 — Audit log (explicit) As a Data Source & Integration Administrator, I should have an audit log so I can check when data entered, was processed, was updated, or failed validation, so that every data event is accountable.

• Trigger/input: the administrator opens Audit Log.
• Observable result: chronological entries record entry, processing, update, and validation-failure events.
• Access state: role-restricted integration administration.
• Failure/recovery: a failed fetch is stated plainly.
• Continuation: the administrator filters or follows an entry to its source.

FR-27 — Security and infrastructure stack (explicit) As a Data Source & Integration Administrator, I should have the product built on React or Next.js frontend, Node.js or Python FastAPI backend, PostgreSQL database, official platform APIs, a synchronization scheduling system, secure credential storage, user authentication and authorization, connection encryption, API access and usage restrictions, and logging and monitoring, so that the platform is operated securely and within platform terms.

• Trigger/input: deployment and operation of the product.
• Observable result: the stated stack and controls are in place.
• Access state: applies to the whole product.
• Failure/recovery: a control failure is logged and monitored.
• Continuation: operation continues within the stated controls.

FR-28 — No API keys in frontend; no bypassing controls (explicit) As a Data Source & Integration Administrator, I should have API keys kept out of frontend code and no authentication, access restriction, or platform term of use bypassed, so that the product's access remains legitimate.

• Trigger/input: any credential handling or API call.
• Observable result: credentials are handled server-side; access controls are enforced.
• Access state: applies to the whole product.
• Failure/recovery: a request that would bypass a control is refused.
• Continuation: legitimate access proceeds.

FR-29 — Verification declaration standard (explicit) As a Market Intelligence Analyst, I should have the product declare data verified only after the relevant checks have successfully passed, so that the word "verified" means something specific.

• Trigger/input: a record or figure is presented as verified.
• Observable result: the verification declaration follows successful checks; otherwise the record is presented with its actual status.
• Access state: applies to all data surfaces.
• Failure/recovery: a record that has not passed checks is not labeled verified.
• Continuation: the analyst reads the actual status.

FR-30 — Acceptance criteria for displayed data (explicit) As a Market Intelligence Analyst, I should have displayed data meet the acceptance criteria — data source identifiable, integration genuinely connected, actual data successfully received, synchronization and its history recorded, displayed figures matching source and measurement period, charts reading from the actual database, connection failures producing no substitute figures, expired data clearly marked, and all access limitations transparently explained — so that what I see meets a stated standard.

• Trigger/input: any data presentation.
• Observable result: each criterion is satisfied or the data is presented with its actual status.
• Access state: applies to all data surfaces.
• Failure/recovery: a criterion that cannot be satisfied results in an explicit status, not a substitute.
• Continuation: the analyst proceeds with data that meets the standard.

FR-31 — Prioritize functioning integration and accuracy (explicit) As a Data Source & Integration Administrator, I should have the product prioritize functioning data integration, measurement accuracy, source transparency, automatic synchronization, and professional charts, so that the platform's effort goes where its promise is.

• Trigger/input: product operation.
• Observable result: these priorities govern what is built and shown.
• Access state: applies to the whole product.
• Failure/recovery: a claim of integration success is withheld until connection testing and data validation complete.
• Continuation: operation continues on verified integrations.

FR-32 — Self-service enrollment (required_inference) As a first-time user, I should enroll through self-service so that I can establish my identity in the product and reach the protected workspace.

• Trigger/input: the user opens Sign Up and submits enrollment details.
• Observable result: identity is established and the user proceeds to the protected workspace.
• Access state: anonymous entry surface.
• Failure/recovery: validation or enrollment failure is stated plainly and the user may correct and resubmit.
• Continuation: the user proceeds to the protected workspace.

FR-33 — Returning verification through Login (required_inference) As a returning user, I should verify my identity through Login so that I can resume my protected work.

• Trigger/input: the user opens Login and submits credentials.
• Observable result: a session is established and the user is returned to the protected destination they were seeking.
• Access state: anonymous entry surface.
• Failure/recovery: invalid credentials are stated plainly with no account-existence disclosure; the user may correct and resubmit.
• Continuation: the user resumes their protected work.

FR-34 — Role assignment and authorization (required_inference) As a Data Source & Integration Administrator, I should have role assignment and authorization govern integration administration and audit access, so that credential handling and audit review are restricted to the role that owns them.

• Trigger/input: a user attempts to reach integration administration or audit surfaces.
• Observable result: access is granted or refused according to the user's role.
• Access state: role-restricted.
• Failure/recovery: a refused attempt is stated plainly and the user is not shown protected state.
• Continuation: the authorized administrator proceeds.

FR-35 — Source authorization and credential setup before private data synchronization (required_inference) As a Data Source & Integration Administrator, I should complete official source authorization and credential setup before private data synchronization begins, so that private data is only retrieved through authorized access.

• Trigger/input: the administrator configures a source that requires authorization.
• Observable result: the source's authorization status is recorded; private data synchronization proceeds only after authorization.
• Access state: role-restricted integration administration.
• Failure/recovery: without authorization the source remains in ACCESS REQUIRED and no private data is retrieved.
• Continuation: the administrator completes authorization and proceeds.

FR-36 — Connection testing and validation before success is presented (required_inference) As a Data Source & Integration Administrator, I should have connection testing and data validation complete before an integration is presented as successful, so that the product never claims an integration succeeded prematurely.

• Trigger/input: the administrator runs a connection test after configuring a source.
• Observable result: the source is presented as connected only after the test and validation complete; otherwise its actual status is shown.
• Access state: role-restricted integration administration.
• Failure/recovery: a failed test leaves the source in its actual status with its cause stated.
• Continuation: the administrator corrects and retests.

FR-37 — Scheduled synchronization and recorded history before metrics, charts, or reports (required_inference) As a Market Intelligence Analyst, I should have scheduled synchronization and recorded update history in place before current metrics, charts, or reports are presented, so that what I see is backed by a recorded run.

• Trigger/input: the analyst opens a data surface.
• Observable result: metrics, charts, and reports are backed by recorded synchronization history.
• Access state: protected workspace.
• Failure/recovery: where no recorded run backs a figure, the figure is not presented as current.
• Continuation: the analyst reads the backed figure.

FR-38 — Validation, completeness, and freshness checks before verification (required_inference) As a Market Intelligence Analyst, I should have data validation, completeness, and freshness checks applied before records are declared verified, so that "verified" reflects checks that actually ran.

• Trigger/input: records enter the verification layer.
• Observable result: validation, completeness, and freshness statuses are recorded and surfaced.
• Access state: protected workspace.
• Failure/recovery: a record failing a check is not declared verified.
• Continuation: the analyst reads the actual status.

4. User Personas

Market Intelligence Analyst

Product context. The analyst is the primary daily operator of SEVPP ANALISIS. Their work is reading a market: which categories are moving, which products are gaining attention, how prices are shifting across sellers, and what the search and campaign data say alongside the marketplace data. They work inside the protected workspace and treat the product as an instrument rather than a report generator.

Primary goal. To reach a defensible read on the market where every displayed metric is traceable to a verified source, period, and retrieval time, and where stale or unavailable data is clearly flagged rather than replaced.

Distinct accepted responsibilities. The analyst monitors the professional market dashboard and applies filters by platform, category, period, price, product, and region. They read the seven interactive charts — market trend, product sales, category performance, price movement, competitor comparison, marketing performance, and market opportunity — and rely on each chart's tooltips, period filters, labels, and source attribution. They review AI market analyst reports and market opportunity scores, and they inspect the data quality surface for validation, completeness, freshness, unusual changes, and conflicting source values.

Relevant inputs and decisions. The analyst decides which market question to pursue, which filters to apply, which chart to read, and which figure to trust when two sources disagree. They decide whether a report's stated uncertainty is acceptable for the decision at hand.

Interactions with other accepted participants. The analyst depends on the Data Source & Integration Administrator for the integrations that supply their data: a source left in ACCESS REQUIRED or ERROR directly limits what the analyst can read. The analyst's verified output is what the Business Strategy Decision Maker consumes, so the analyst's traceability work is what makes the decision maker's conclusions defensible.

Observable success. Every metric the analyst reads carries its source, retrieval time, and measurement period; stale data is marked; unavailable data is stated as unavailable; discrepancies between sources are shown rather than merged; and no chart shows a curve that was not measured.

Data Source & Integration Administrator

Product context. The administrator owns the data supply side of SEVPP ANALISIS. Their work is connecting and authorizing official marketplace and marketing platform integrations — Shopee, Tokopedia, Lazada, TikTok Shop, Google Trends, Google Analytics, Google Search Console, Meta Ads Library, and other officially accessible analytics platforms — managing secure credential storage, and keeping the synchronization engine healthy.

Primary goal. To have integrations genuinely connected, synchronization and its history recorded, and access limitations transparently explained, so that the analyst's data supply is real and auditable.

Distinct accepted responsibilities. The administrator configures and authorizes sources, runs connection tests, and manages secure credentials. They monitor per-source connection status across CONNECTED, SYNCING, VERIFIED, STALE, ERROR, and ACCESS REQUIRED, and they review synchronization history, successfully processed and failed record counts, and error notes. They maintain the audit log and review the data quality surface for records that failed validation.

Relevant inputs and decisions. The administrator decides which sources to connect, which credentials to supply, whether a source's authorization is sufficient for the private data it is expected to provide, and whether a failing source should be retested or left in its actual status.

Interactions with other accepted participants. The administrator's work directly determines what the Market Intelligence Analyst can read: a source in ACCESS REQUIRED or ERROR is a limit the analyst must see. The administrator's audit log is what allows the Business Strategy Decision Maker's conclusions to be traced back to a recorded synchronization event.

Observable success. Every integration shows its real status; no integration is presented as successful before connection testing and data validation complete; connection status is never presented as a guarantee of completeness; public and private data are distinguished; and every data event is recorded in the audit log.

Business Strategy Decision Maker

Product context. The decision maker consumes the verified market intelligence output rather than operating the data pipeline. Their work is deciding where to invest or act, based on the highest-growth categories, products gaining attention, competitor analysis, business opportunities, market risks, and digital marketing strategy recommendations the product produces.

Primary goal. To reach investment and strategy decisions where conclusions are supported by cited data sources and stated uncertainty, and where popularity is never mistaken for proven margin.

Distinct accepted responsibilities. The decision maker reads AI market analyst reports and market opportunity scores, compares opportunities on the stated indicators and calculation methods, and weighs demand against margin potential separately. They follow cited sources back to the underlying records and charts when a conclusion matters.

Relevant inputs and decisions. The decision maker decides which opportunity to pursue, which risk to hedge, and which recommendation to act on. They decide whether the stated data completeness and uncertainty are sufficient for the commitment they are considering.

Interactions with other accepted participants. The decision maker depends on the Market Intelligence Analyst's traceable output and on the Data Source & Integration Administrator's recorded synchronization history. When a report cites a source, the decision maker can follow it to the record the analyst reviewed and the run the administrator recorded.

Observable success. Every conclusion the decision maker acts on cites its supporting data sources; uncertainty is stated where evidence is insufficient; margin potential is stated only where cost data is known; and no score presents popularity as proof of profitability.

5. Core User Flows

Flow 1 — First-time enrollment and first look at the market (Market Intelligence Analyst)

1. The analyst arrives at Landing anonymously. The masthead shows the wordmark and a one-line statement of the product's actual current state generated from real integration status, and the nine-row source panel shows each registered platform with its real status word.
2. The analyst reads the source panel and sees which integrations are VERIFIED, STALE, ERROR, or ACCESS REQUIRED before entering. No protected state is shown.
3. The analyst selects Sign Up and submits enrollment details.
4. The product establishes the analyst's identity. On success, the analyst proceeds to the protected workspace. On validation failure, the form states the failure plainly and the analyst corrects and resubmits.
5. The analyst lands on Dashboard. The six metric tiles render with their figures, source chips, and measurement periods; the filter bar is visible and does not collapse.
6. The analyst applies filters by platform, category, period, price, product, and region. Filters the source does not support are shown as unsupported rather than silently applied.
7. The analyst reads a metric. Where a metric has no available data, the tile states the reason — no source, no records, or insufficient history — instead of showing a zero.
8. The analyst drills into a metric and proceeds to Charts.

Flow 2 — Reading the market charts (Market Intelligence Analyst)

1. The analyst opens Charts from the protected workspace.
2. The analyst selects a chart — Market Trend, Product Sales, Category Performance, Price Movement, Competitor Comparison, Marketing Performance, or Market Opportunity.
3. The chart draws from the synchronized database. The caption row beneath it carries the source name, retrieval timestamp, and measurement period.
4. The analyst applies a period filter and hovers for tooltips. Axis labels and source attribution remain visible.
5. Where historical data is insufficient, the chart states the reason and shows no curve. No fabricated history is drawn to fill the panel.
6. Where the chart's data cannot be fetched, the panel shows an explicit unavailable state with no substitute figure.
7. The analyst follows the source attribution to the underlying record in Data Quality, or proceeds to AI Reports.

Flow 3 — Reviewing an AI market analyst report (Market Intelligence Analyst)

1. The analyst opens AI Reports and requests or opens a report.
2. The report presents its sections: current market conditions, highest-selling products based on available data, highest-growth categories, products starting to gain attention, consumer interest changes, competitor analysis, business opportunities, market risks, digital marketing strategy recommendations, and supporting data sources for conclusions.
3. Where evidence is insufficient for a section, the section states that evidence is insufficient rather than concluding.
4. The analyst follows a cited supporting data source to the underlying record or chart.
5. Where report generation fails, the failure is stated plainly with no partial fabricated content, and the analyst may request the report again.

Flow 4 — Comparing market opportunities (Business Strategy Decision Maker)

1. The decision maker opens Opportunity Scores from the protected workspace.
2. The decision maker opens a score and reads its indicator breakdown: sales growth where available, search interest growth, trend consistency, competition level, price changes, margin potential based on known costs, data completeness, and demand change risk.
3. The score explains its calculation method. An indicator whose data is unavailable is shown as unavailable rather than scored as zero.
4. The decision maker reads margin potential separately from demand. Where cost data is unknown, margin potential is stated as unavailable, and popularity is not presented as proof of profitability.
5. The decision maker follows an indicator to its underlying chart or record, or proceeds to AI Reports for the supporting analysis.
6. Where score computation fails, the failure is stated plainly and the decision maker may retry.

Flow 5 — Connecting and authorizing an official source (Data Source & Integration Administrator)

1. The administrator opens Integrations and sees each registered source with its platform name, connection status, available data types, last synchronization time, update frequency, processed and failed record counts, error notes, authorization status, and synchronization history.
2. The administrator selects a source that requires authorization and opens Integration Setup.
3. The administrator enters or updates credentials for the source. Credentials are handled securely and never placed in frontend code.
4. The administrator runs a connection test. The source is presented as connected only after connection testing and data validation complete; until then its actual status is shown.
5. On a failed test, the cause is stated and the source remains in its actual status — for example ACCESS REQUIRED or ERROR. The administrator corrects the credentials and retests.
6. On success, the administrator saves and authorizes the source. Public data and private data available only through seller or advertiser accounts are distinguished, and private data synchronization proceeds only after authorization.
7. The administrator returns to Integrations, where the source now shows its real status and its synchronization history begins to record runs.

Flow 6 — Monitoring source health and synchronization history (Data Source & Integration Administrator)

1. The administrator opens Integrations and reviews each source's status across CONNECTED, SYNCING, VERIFIED, STALE, ERROR, and ACCESS REQUIRED.
2. The administrator reads a source's last synchronization time, update frequency, successfully processed record count, failed record count, and error notes.
3. The administrator does not treat a healthy connection as a guarantee that all data is complete; completeness is read separately.
4. Where a source is in ERROR, the administrator reads the error note and no substitute counts are shown.
5. The administrator reviews the source's synchronization history and proceeds to Audit Log to see when data entered, was processed, was updated, or failed validation.
6. Where a scheduled run failed, the retry outcome is reflected in the source's status and history.

Flow 7 — Reviewing data quality and cross-source discrepancies (Market Intelligence Analyst)

1. The analyst opens Data Quality and reviews records by validation status, completeness status, and freshness status.
2. The analyst opens a record and reads its source name, source ID where available, retrieval time, source update time where available, data period, validation status, completeness status, freshness status, and limitation notes.
3. Where two sources disagree, the analyst sees both figures side by side with the delta and both measurement periods between them. The figures are never averaged into one.
4. The analyst decides which figure to use and proceeds to the corresponding chart or report.
5. Where a record failed validation, the analyst follows it to Audit Log to see the corresponding event.

Flow 8 — Acting on verified intelligence (Business Strategy Decision Maker)

1. The decision maker opens AI Reports and reads a report whose conclusions cite their supporting data sources.
2. The decision maker follows a citation to the underlying record in Data Quality or the underlying chart in Charts.
3. The decision maker checks the record's measurement period and freshness status, and reads any stated uncertainty.
4. Where the evidence is insufficient for the commitment being considered, the decision maker sees that stated rather than a conclusion.
5. The decision maker proceeds to Opportunity Scores to compare the opportunity against alternatives on the stated indicators.
6. The decision maker reaches a decision supported by cited sources, or defers it where the stated uncertainty is too high.

6. Visuals, Colors, and Theme

The creative direction is authoritative for this section: Less, but better — a Braun-panel instrument for verified market data, with Dieter Rams as the muse. The product's promise is that it never dresses a number up, so the interface is built as a measuring instrument: honest controls, aligned label/value pairs, one signal colour that means something, and no decoration that is not also information.

Mode. Dark mode is the primary and only mode.

Colour tokens by role:

Signal semantics. Signal red #E4002B is rationed: it marks the primary action, the one highest-growth category, ERROR and STALE flags, and the single filled segment of any gauge — never large background fields. Amber #FFB000 is the second signal, reserved for ACCESS REQUIRED and for "data insufficient" states, so red/amber/green-ish semantics stay legible. White is used as a full-width band exactly once per page — the verification ledger strip — to break the dark ground.

Proportion target: 70% black/panel, 22% off-white type and rules, 6% red, 2% amber.

Typography. Headings and body are Archivo. Headings are set at 500–600 with tracking tightened to -0.02em; body is 400 at 16–18px. Labels, status chips, units, and table headers are Archivo 600, uppercase, 11–12px, tracking +0.14em — the small-caps label voice of a control panel. Numbers are the loudest thing on every screen: Archivo 700, tabular-nums, set at 2.4–3.4× the label size so a figure always outweighs its caption. No italic, no light weights, no display serif.

Type scale. 1.25 modular on a 4px baseline: 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49 / 61 / 76px. Body 16px, table body 14px, labels 11–12px, metric numerals 31–49px depending on column count, hero headline clamp(40px, 7.2vw, 76px) with 1.02 line-height.

Shape language. Rounded-rectangle controls with a single 6px radius on buttons, chips, inputs, and panels — Braun radio-bezel geometry, never pills, never fully square. 1px hairline rules everywhere a border is meaningful; 2px rules only as section dividers. Gauges are circles with a 3px arc stroke and a thick needle. No blobs, no soft shadows larger than 8px, no glass, no gradient fills except a 4% black scrim over chart plot areas.

Spacing rhythm. 4px baseline; 8px intra-component, 16px between related elements, 24px between panels, 48px between sections.

Layout. A strict 12-column modular grid at 1280px, 6 columns at 768px, 2 columns at 375px, with a persistent left rail of numbered sections (01 Dashboard, 02 Charts, 03 Analyst, 04 Opportunity, 05 Sources, 06 Audit) that behaves like a device legend. Data is always presented as aligned label/value pairs with the label left and the figure right-aligned to a shared numeric edge — the same edge across every card in a row. The dashboard is dense but ordered: 6 metric tiles in a 3×2 block, then a 2/3 + 1/3 split of a primary chart beside a source-and-freshness column. Every chart sits in a panel with a caption row beneath it carrying source name, retrieval timestamp, and measurement period in 12px uppercase. Filters live in a single horizontal control bar that never collapses into a hidden drawer.

Imagery style. No photography. The visual vocabulary is diagrammatic: schematic line icons for each platform source, hairline sparklines, ruled ledgers, needle gauges, and a small set of 2px-stroke pictograms for data states (plug, clock, shield-check, warning triangle). The one permitted "image" is an abstract verification mark — a circular stamp drawn with concentric hairlines and the word VERIFIED in 11px uppercase — used as a watermark on records that passed checks. Anything decorative that cannot be read as information is cut.

Readable text and controls stay whole at every viewport. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. The verification ledger band is a moving strip and may cross the viewport edge by design; every item becomes fully readable as it passes, and under prefers-reduced-motion it wraps into rows or becomes horizontally scrollable so each item can be brought fully into view.

7. Signature Design Concept

The control-panel masthead and the verification ledger band.

The public entry is not a marketing hero. It is a full-bleed #111111 ground carrying a control-panel masthead, and it exists to show the product's honesty as the first thing on screen rather than as a claim.

Left 8 columns. The wordmark SEVPP ANALISIS in Archivo 600 uppercase at clamp(40px, 7.2vw, 76px) with tracking -0.02em, stacked over a 2px red rule (#E4002B) that runs the full 8 columns. Beneath the rule, one line of 16px muted copy (#8A8A85) stating the actual state — for example "9 sumber terdaftar · 4 terverifikasi · pembaruan terakhir 14:02 WIB" — generated from real integration status, never a promise. There is no centred headline, no sub-headline-plus-button stack, no gradient, and no illustration.

Right 4 columns. A vertical stack of nine source rows. Each row is a hairline-ruled label/value pair with the platform name in 12px uppercase, a 10px status LED, and its status word in 11px uppercase — CONNECTED, SYNCING, VERIFIED, STALE, ERROR, or ACCESS REQUIRED. The first screen therefore already shows exactly which integrations are verified, stale, or awaiting authorization.

Across the bottom. A single full-width white band (#F4F2EE) carries the last-sync ledger as a horizontally scrolling strip of records — source, record count, timestamp — with black type on white. It is the only white field in the design, and it moves continuously, pausing on hover.

Why this is the signature. The nine-row live source panel and the ledger band are the product's two defining states — what is connected, and what was actually retrieved — rendered as the first thing a visitor sees. The concept recomposes only accepted content and states: registered sources, their real statuses, record counts, and retrieval times. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject. The nine-row live source panel and the verification ledger band — the product's real integration state and its real retrieval record.
• Input → transformation → outcome thesis. The page loads with real integration status; the source rows resolve from an unresolved state into their actual statuses with their status LEDs; the ledger band begins its continuous horizontal movement carrying source → records processed → retrieval time. The outcome is that the visitor reads the product's honesty before reading any claim.
• Motion vocabulary. Instant, mechanical, state-change only. Numbers tick to their value in 240ms with linear easing and stop. Status LEDs cross-fade between red, amber, and off in 120ms. The ledger band moves continuously and pauses on hover. The sync indicator is the only looping element: a 1.2s hard-step blink on the SYNCING chip.
• Composed first frame. Full-bleed #111111 ground. Left 8 columns: the wordmark stacked over the 2px red rule, with the muted state line beneath. Right 4 columns: nine hairline-ruled source rows, each with its LED and spelled-out status. Across the bottom: the white ledger band, already moving.
• Reduced-motion state. Under prefers-reduced-motion everything renders in its final state: the SYNCING blink becomes a static filled dot, the number tick is removed, and the ledger band stops moving and wraps into rows or becomes horizontally scrollable so every record can be brought fully into view.

9. Non-Functional Requirements

NFR-01 — Data authenticity (explicit) All system data must originate from official APIs, authorized integrations, or verifiable public sources. Simulated data, fabricated figures, and data without a clear source are prohibited. Rationale: the product's entire value is that its figures are measurements.

NFR-02 — Traceability (explicit) Every figure must be traceable to its source, retrieval time, and measurement period. Rationale: a figure that cannot be traced cannot be defended or acted on.

NFR-03 — Honest currency claims (explicit) The product must not claim real-time data where the source does not support real-time updates. Rationale: freshness claims are themselves data and must be as honest as the figures.

NFR-04 — No substitute figures on failure (explicit) Connection failures must not produce substitute figures; expired data must be clearly marked; all access limitations must be explained transparently. Rationale: a gap must read as a gap.

NFR-05 — Verification before declaration (explicit) The website may only declare data verified after the relevant checks have successfully passed. Rationale: "verified" must denote a completed check, not an assumption.

NFR-06 — No premature integration success claims (explicit) An integration must not be claimed successful before connection testing and data validation are complete. Rationale: a connected-looking source that returns nothing is worse than an honestly failing one.

NFR-07 — Credential security (explicit) API keys must not be placed in frontend code; credentials must be stored securely; connection encryption must be used. Rationale: credential exposure would break both the product's security and its platform authorizations.

NFR-08 — Access and usage restrictions (explicit) API access and usage must be restricted and must respect platform limits; authentication, access restrictions, and platform terms of use must not be bypassed. Rationale: the product's access to official sources depends on remaining within their terms.

NFR-09 — Authentication and authorization (explicit) User authentication and authorization must be enforced, with integration administration and audit access restricted to the role that owns them. Rationale: credential handling and audit review are sensitive responsibilities.

NFR-10 — Logging and monitoring (explicit) Logging and monitoring must be in place across synchronization, validation, and access. Rationale: the audit trail and the source monitoring surfaces depend on recorded events.

NFR-11 — Public/private data separation (explicit) Public data must be separated from private data available only through seller or advertiser accounts. Rationale: the product must never imply access it does not have.

NFR-12 — No merging of unlike figures (explicit) Figures whose definitions or periods differ must not be merged; the difference must be shown instead. Rationale: merging unlike measurements produces a number that corresponds to no source.

NFR-13 — No fabricated history (explicit) Fake history must not be created to fill charts when historical data is insufficient. Rationale: the shape of a curve is itself a claim.

NFR-14 — AI evidence discipline (explicit) AI may only use genuinely available data and must state uncertainty when evidence is insufficient. Rationale: an AI conclusion is only as defensible as the data behind it.

NFR-15 — Popularity is not profitability (explicit) Popularity must not be treated as proof of profitability. Rationale: high demand and good margin are different measurements.

NFR-16 — Connection status is not completeness (explicit) Successful connection status must not be equated with a guarantee that all data is complete. Rationale: a healthy connection can still return partial data.

NFR-17 — Readable text and controls at every viewport (required_inference) Readable text and controls must remain whole and uncovered at 375px, 768px, and 1280px. Rationale: the product's figures and labels are its content; a cropped figure is a misread figure.

10. Tech Stack

Source-specified choices are preserved exactly.

• Frontend: React or Next.js. (explicit)
• Backend: Node.js or Python FastAPI. (explicit)
• Database: PostgreSQL. (explicit)
• Data sources: official platform APIs, authorized business accounts, or licensed third-party data providers with the right to supply the data — Shopee, Tokopedia, Lazada, TikTok Shop, Google Trends, Google Analytics, Google Search Console, Meta Ads Library, and other officially accessible marketing analytics platforms. (explicit)
• Synchronization scheduling: a synchronization scheduling system for scheduled runs, webhook intake where a platform provides it, automatic updates within API limits, and retry on connection failure. (explicit)
• Credential storage: secure credential storage, server-side only; API keys must not be placed in frontend code. (explicit)
• Authentication and authorization: user authentication and authorization, with role-restricted integration administration and audit access. (explicit)
• Transport security: connection encryption. (explicit)
• API governance: API access and usage restrictions respecting platform limits and terms of use. (explicit)
• Observability: logging and monitoring across synchronization, validation, and access. (explicit)
• AI analysis: an AI integration that analyzes synchronized data and produces the required report sections, using only genuinely available data and stating uncertainty when evidence is insufficient. (explicit)

• Caching and job coordination: Redis for synchronization job coordination, retry scheduling, and short-lived status caching. (required_inference — the synchronization engine's scheduling, retry, and per-source status monitoring require shared job state and fast status reads.)
• Containerization: Docker and docker-compose for the frontend, backend, PostgreSQL, Redis, and the synchronization worker. (required_inference — the product requires a persistent backend, a database, a cache/job store, and a scheduled worker to run together.)

11. Assumptions and Constraints

Assumptions

• A-01: The product is delivered as a first-party web application with application-owned identity, because the source establishes user authentication and authorization and no invitation or provisioning boundary. (required_inference)
• A-02: First-use enrollment is self-service, because the source establishes authentication but names no invitation, provisioning, or deployment bootstrap path. (required_inference)
• A-03: Integration administration and audit access are role-restricted, because the source establishes authorization and the handling of credentials and audit records is a distinct responsibility from reading market intelligence. (required_inference)
• A-04: Where a platform does not expose a public API for a given data type, that data type is not synchronized from that platform and is shown as unavailable. (explicit)
• A-05: Private data available only through seller or advertiser accounts is synchronized only after the corresponding authorization is completed. (explicit)
• A-06: The nine named platforms are the current integration targets; additional marketing analytics platforms are in scope only where they provide official access. (explicit)
• A-07: The product's public entry surface is anonymously reachable and carries no protected state. (required_inference)

Constraints

• C-01: Simulated data or fabricated figures are prohibited. (explicit)
• C-02: Displaying data without a clear source is prohibited. (explicit)
• C-03: Claiming real-time data when the source does not support real-time updates is prohibited. (explicit)
• C-04: Fabricating sales counts, revenue, demand, or competitor performance is prohibited. (explicit)
• C-05: All platforms must not be assumed to have public APIs for all sales data. (explicit)
• C-06: Public data must be separated from private data available only through seller or advertiser accounts. (explicit)
• C-07: Successful connection status must not be equated with a guarantee that all data is complete. (explicit)
• C-08: Figures whose definitions or periods differ must not be merged; the difference must be shown instead. (explicit)
• C-09: Fake history must not be created to fill charts when historical data is insufficient. (explicit)
• C-10: AI may only use genuinely available data and must state uncertainty when evidence is insufficient. (explicit)
• C-11: Popularity must not be treated as proof of profitability. (explicit)
• C-12: API keys must not be placed in frontend code. (explicit)
• C-13: Authentication, access restrictions, and platform terms of use must not be bypassed. (explicit)
• C-14: An integration must not be claimed successful before connection testing and data validation are complete. (explicit)
• C-15: The website may only declare data verified after the relevant checks have successfully passed. (explicit)
• C-16: Connection failures must not produce substitute figures; expired data must be clearly marked; all access limitations must be explained transparently. (explicit)

Future requirements

No future-horizon requirements were stated in the authoritative source. All requirements in this document are current.

12. Glossary

• SEVPP ANALISIS — the product name for this digital market intelligence platform, subtitled "Economic Research & Investment Insight."
• Verified data — data that has passed the checks the product defines (source identification, connection, actual receipt, recorded synchronization, consistency, format, duplication, and unusual-change checks) and may therefore be declared verified.
• Data record — a single synchronized measurement carrying source name, source ID where available, retrieval time, source update time where available, data period, validation status, completeness status, freshness status, and limitation notes.
• Integration — a configured connection between SEVPP ANALISIS and an official data source, with its own authorization status, synchronization schedule, and history.
• Synchronization run — a single execution of the synchronization engine against a source, whether scheduled, webhook-triggered, or administrator-initiated, whose outcome is recorded in history.
• Connection status — one of CONNECTED (connection succeeded), SYNCING (synchronization in progress), VERIFIED (data passed the defined checks), STALE (data available but past the defined freshness limit), ERROR (a data retrieval error occurred), or ACCESS REQUIRED (authorization or credentials are needed).
• Freshness status — whether a record is within the defined freshness limit for its source, and therefore whether it is current or stale.
• Completeness status — whether the data expected from a source was actually received, independent of whether the connection is healthy.
• Measurement period — the time span over which a figure was measured at its source, distinct from the time it was retrieved.

• Discrepancy — a case where two sources supply different values for the same measurement, shown side by side with the delta and both measurement periods rather than merged.
• Audit log — the chronological record of when data entered, was processed, was updated, or failed validation.
• Market opportunity score — a score built from sales growth where available, search interest growth, trend consistency, competition level, price changes, margin potential based on known costs, data completeness, and demand change risk, with its indicators and calculation method explained.
• Public data — data available without seller or advertiser authorization.
• Private data — data available only through a seller or advertiser account, synchronized only after the corresponding authorization is completed.