Slack Analytics Intelligence
One architect built the intelligence layer an entire organization queries daily. Analytics from 6+ client sites flow through BigQuery into Slack channels — no dashboards, no analyst queue, no context switching.
The Problem
Analytics data for 6+ client websites lived in separate GA4 properties, each requiring manual login to Google Analytics to check performance. Search Console data lived in yet another interface. Microsoft Clarity heatmaps in a third. Facebook Pixel conversion data in a fourth.
The result: nobody checked analytics proactively. Data existed but wasn't actionable. When someone needed a number, they'd spend 15 minutes navigating dashboards to find it. Most of the time, they didn't bother. Critical trends — traffic drops, conversion changes, indexing issues — went unnoticed until they became emergencies.
The Approach
The insight was that people already live in Slack. If the data comes to where they already are, they'll engage with it. The architecture has three layers:
Layer 1: Collection
A Cloudflare Worker runs daily at 03:00 UTC, pulling GA4 metrics and Search Console data via Google APIs for all properties. Raw data writes to BigQuery tables (daily_site_metrics, daily_keyword_rankings) with standardized schemas across all sites.
Layer 2: Transformation
n8n workflows query BigQuery on schedule, computing week-over-week deltas, trend detection, and anomaly flagging. Each workflow is purpose-built: one for morning intelligence briefs, one for emergency alerts, one for weekly rollups.
Layer 3: Delivery
Formatted intelligence posts to dedicated Slack channels. #morning-reports-analytics gets the daily brief. #alerts-critical gets anomaly alerts. Each message includes context — not just "traffic dropped 15%" but "traffic dropped 15% on masumihayashi.com, likely related to the indexing issue detected yesterday."
Key Architectural Decision
The original design used Cloudflare Workers for Slack delivery. It failed — silently. Slack blocks requests from known datacenter IP ranges (ASN-based filtering) as a defense against automation abuse. The code was correct. The authentication was correct. The network topology was the problem.
The solution: n8n running locally on a residential IP address. This isn't a workaround — it's the correct architecture for this constraint. Integration platforms like n8n and Zapier exist precisely because they handle the IP reputation problem that cloud-native deployment can't solve. This discovery led to the Platform Defense Maturity Model framework.
Results
The pipeline runs autonomously. Analytics data that previously required manual dashboard navigation now arrives in Slack channels before the morning coffee. Anomalies trigger immediate alerts. Weekly rollups provide trend context. The entire organization's analytics intelligence runs on infrastructure one architect designed and maintains.