← Về thư mục
📄 / / root / ceo-project / profiles / glv / brand_monitoring / docs / brand-monitoring-architecture-draft-recovered.md

IT.01 Brand Monitoring Architecture Draft

Scope and principles

This architecture is designed for public-data-only brand monitoring with three priorities:

  1. Brand health visibility across many brands.
  2. Crisis-first alerting and escalation.
  3. Low operational complexity with no dependency on private page APIs.

The system should assume that some sources are available via RSS, public web pages, public search results, social public endpoints, and manual uploads. The architecture should degrade gracefully when a source is temporarily unavailable.

Ingestion layers

  1. Public discovery layer
  2. RSS/Atom feeds
  3. Public news pages
  4. Public blog pages
  5. Public social posts where accessible without private API access
  6. Public forum / community pages

  7. Google Alerts-style search-driven discovery where needed

  8. Normalization layer

  9. Canonical brand entity mapping
  10. Source URL normalization
  11. Deduplication by URL, content fingerprint, and near-duplicate text hash
  12. Language detection

  13. Basic sentiment / severity tagging

  14. Triage layer

  15. Crisis keyword and anomaly detection
  16. Volume spikes
  17. Negative sentiment spikes
  18. High-authority source mentions

  19. Executive/priority brand override rules

  20. Storage and reporting layer

  21. Operational store for raw events and normalized mentions
  22. Summary tables for daily/weekly reporting
  23. Alert queue for crisis-first notifications
  24. Archived reports for trend history and audits

Core design choice

Use a simple pipeline:

Public sources -> collector jobs -> normalize/dedupe -> severity scoring -> storage -> dashboard + alerts + archive

This keeps the system explainable and easy to operate. It also avoids over-engineering for a first version.

Storage recommendation: Google Sheet vs Airtable vs SQLite

Option A: Google Sheets

Pros: - Familiar for non-technical operators - Fast to inspect manually - Good for lightweight reporting - Easy export/share

Cons: - Weak data modeling - Limited deduplication / relational structure - Not ideal for large-scale event volume - Concurrency and formula complexity become painful - Harder to preserve raw event history cleanly

Best use: - Executive report views - Manual review queue - Simple stakeholder-facing status sheet

Option B: Airtable

Pros: - Better structure than Sheets