What the dashboard should be

The dashboard should be positioned as the control plane for an analytics namespace — not just
“site analytics.”

The clearest framing is:

• ANALYTICS.1 = the Web3-native analytics endpoint and namespace brand
• Web2 twin (e.g., analytics1.site / analytics.website) =
  onboarding, HTTPS access, documentation, and the dashboard UI
• The dashboard is where operators, partners, and subdomain tenants monitor performance, campaigns,
  and revenue across the ecosystem.

Best use of the dashboard

This should be a multi-tenant analytics console that supports the Web-3 Network as it scales
across many TLD landing pages, partner pages, and hosted programmes.

1. The Web-3 Network
   Track each TLD site, landing page, and partner page as a “tenant,” including:
   • traffic and conversion funnels
   • partner campaign performance
   • lead submissions and signups
   • lease inquiries and purchases
   • affiliate and referrer attribution
2. On-chain + off-chain in one view (dual stack)
   Combine:
   • Web events (page views, CTA clicks, form submits)
   • Campaign metadata (UTM, referrer, partner)
   • On-chain signals (mints, leases, payments, wallet connects) where applicable
3. A “generic endpoint” model
   What this enables:
   • tenant.analytics.1 as a namespace concept (even if routed via gateways today)
   • api.analytics.1 as the ingest/query brand (hosted on Web2 but branded as the root)
   • a future “verified analytics” directory (optional)

Operator opportunity: In addition to providing analytics for the Web-3 Network and earning
income from this, the operator of Analytics1.site and Analytics.1 can also
offer analytics services externally to other projects and partners.

Phased build

Phase 1 (MVP)

• Dashboard UI
• Event tracking snippet (one JS file)
• Ingest endpoint (POST events)
• Basic reports: KPIs, time series, top pages, top referrers, campaign performance, conversions

Phase 2 (Real product)

• Multi-tenant RBAC (admin / partner / viewer)
• Alerts (spikes, drops, suspected bot traffic)
• Export + API keys per tenant
• Consent + privacy settings (GDPR-friendly)

Phase 3 (Web3-native differentiator)

• Wallet-based access (e.g., SIWE) where helpful
• On-chain indexing integration (RPC indexing, subgraphs, or an indexer service)
• Optional attestations/proofs for auditable campaign metrics

Architecture (simple and scalable)

• Frontend: React + Tailwind + Recharts (fast to ship, good visuals)
• Backend API: Node/Express for ingest + query (MVP), or Next.js route handlers if preferred
• Storage: start with Postgres; add ClickHouse later for high-volume event analytics
• Event model (v1):
  tenant_id, event, url, referrer, utm_*,
  wallet (optional), timestamp

Production-ready starter (overview)

This starter can run in minutes and includes:

• A modern analytics dashboard UI (tenant selector, KPIs, charts, tables)
• A simple backend with:
  • POST /api/events (ingest)
  • GET /api/metrics (dashboard query)
• Real sources can be wired later (PostHog, Plausible, GA4 export, ClickHouse, on-chain indexers, etc.).

Run backend (example commands)

mkdir analytics-1 && cd analytics-1
npm init -y
npm i express cors

# Enable ESM:
node -e "const p=require('./package.json'); p.type='module'; require('fs').writeFileSync('package.json', JSON.stringify(p,null,2));"

# Add server.js, then:
node server.js

Create the frontend project

# In a new terminal:
npm create vite@latest analytics-dashboard -- --template react
cd analytics-dashboard
npm i recharts
npm i
npm run dev

Add Tailwind

npm i -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Update tailwind.config.js:

export default {
  content: ["./index.html", "./src/**/*.{js,jsx}"],
  theme: { extend: {} },
  plugins: [],
};

Update src/index.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

Replace src/App.jsx with your React dashboard code.

Deployment under ANALYTICS.1 (dual-stack)

Recommended deployment pattern:

• Host the dashboard at your Web2 twin (e.g., https://analytics1.site/dashboard or
  https://analytics.website/dashboard)
• Brand the product as ANALYTICS.1 Dashboard
• Provide gateway access links like https://hns.to/analytics.1 that route users to the Web2 dashboard

Who it serves best:

• Web-3 Network admin: oversees all Web-3 Network tenants
• Partners: view their own tenant dashboards
• Future buyers: immediately understand the “namespace-as-a-network” story

What to build next to increase value quickly:

1. Add tenant onboarding + API keys
2. Add role-based access (admin/partner/viewer)
3. Add conversion funnels and a simple alert system
4. Add on-chain event ingestion (wallet connect, mints, lease payments)

Tip: Keep the dashboard on the Web2 twin for HTTPS trust. Treat ANALYTICS.1 as the namespace and API brand.