How to connect Google Analytics to Slack without crying wolf

Analytics in a chat channel goes one of two ways. Either it becomes a daily number nobody reads because it carries no comparison, or it becomes an alert stream that fires every Monday morning because traffic is always lower at the weekend, and within a month everybody has muted it.

Both are avoidable, and the fixes are specific: give every number a comparison, build baselines that know what day it is, and be honest on the face of the message about what GA4 is and is not telling you.

What we'll cover

• Reports, not alerts
• Baselines that know what day it is
• Building it with CodeWords
• Five messages worth sending
• Being honest about the number
• Detecting tracking that broke
• Who should receive which report
• Formatting a number so it gets read
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

Reports, not alerts

The framing that decides whether this works.

An alert says something is wrong and somebody must act. Very few analytics movements meet that bar, and treating ordinary variance as an alert destroys the credibility of the ones that do.

A report says here is what happened, on a schedule, read when convenient. Most analytics belongs here.

The exceptions are genuine breaks: conversions gone to zero, a traffic source vanished, tracking stopped. Those are alerts because they mean something is broken rather than different.

Everything else is a report — weekly traffic, campaign performance, content digests — and is better delivered once at a consistent time than as movements throughout the day.

The practical consequence: build the weekly report first and add alerts sparingly, rather than starting with alerts and gradually turning them all off.

Baselines that know what day it is

Almost every false alarm in analytics alerting comes from a baseline that ignores the calendar.

Compare against the same weekday. Web traffic has a strong weekly rhythm, and comparing Monday against Sunday produces an alert every Monday.

Use several recent weeks, and a median. A mean is dragged around by one unusual day, and a median of the last four same-weekdays is stable and simple.

Account for known events. A campaign launch, a release, or a public holiday produces movement that is not an anomaly, and an alert that fires anyway teaches people to dismiss it.

Require a minimum volume. A percentage change on small numbers is meaningless, and low-traffic segments generate most of the noise.

Alert on sustained change, not a single point. Two or three consecutive periods outside the range is a signal; one is usually nothing.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which property, which metrics, over what period, and where the message goes.
3. Authorize the connection with a Google service account granted read access to the property, and to your Slack workspace.
4. Describe the exceptions: a sampled response, a thresholded result, a figure outside a plausible range, an empty result.
5. Run it against a period where you already know the answer and compare against the interface.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Five messages worth sending

The weekly report. Traffic, conversions, and top sources, each with the comparison already calculated, before the meeting rather than during it.

Conversion tracking broken. A goal or event that has gone to zero, which is the highest-value alert here because it produces no error anywhere else.

A traffic source that has vanished. Referral traffic from a partner disappearing, or organic dropping sharply, both of which have causes worth investigating quickly.

Campaign performance during a campaign, daily and only while it is running, to whoever is spending the money.

A content digest, weekly, to whoever writes the content — which pages gained and lost, with the comparison. This is the report content teams ask for and rarely get.

Being honest about the number

GA4 will sometimes hand you an estimate, and a message that presents it as exact is a credibility problem the first time somebody checks against the interface.

Put the caveat in the message, not in a footnote. The response metadata says whether sampling or thresholding affected the result; a single word beside the figure is enough.

Never let the automation smooth over a gap. If a breakdown came back with rows withheld, the message should say the total does not equal the parts rather than quietly presenting a subtotal.

Say which property and which timezone. Most disputes about a figure being wrong by a day end there, and putting it in the message ends them before they start.

Flag a figure that is implausible rather than sending it. Reporting revenue as zero because a configuration changed is worse than reporting nothing, and a channel is a bad place to be confidently wrong.

Keep the caveats short. One clause, every time, in the same place. Caveats that vary in wording get read as new information; identical ones become background the reader trusts.

The GA4 integration page covers why these behaviours exist and how to work around them. Here, the point is narrower: whatever the data says, the message should not claim more than it knows.

Detecting tracking that broke

The most valuable thing here, and the one nobody builds until after it has cost them.

Instrumentation breaks on release, silently. Nothing errors; the events simply stop arriving.

Alert on absence, not on decline. A conversion event going to zero is the characteristic symptom, and a threshold-based alert cannot fire on data that is not there.

Check the events that matter individually, not total volume, since one broken event is invisible in an aggregate.

Include the last time it was seen, which usually points straight at the release that broke it.

Check configuration too. Events that stopped being marked as conversions, or custom dimensions no longer registered, produce the same symptom with a different cause.

Who should receive which report

Marketing gets campaigns and sources, while campaigns are live rather than always.

Content gets the page-level digest, weekly, with movement rather than levels.

Engineering gets the tracking health alerts, since they are the ones who will fix them.

Leadership gets one number, weekly, with comparison — not a dashboard link, which nobody opens.

Nobody gets everything. A channel receiving all of the above is a channel where the tracking-broken alert sits unread beneath a content digest.

Formatting a number so it gets read

The craft half, and it decides whether a scheduled report survives past its second week.

Lead with the change, not the level. "Signups down 18% against last Tuesday" is read. "Signups: 412" is not, because nobody knows whether that is good.

Put the comparison in the sentence, not in a second line somebody has to assemble mentally.

Give the absolute alongside the percentage. A 40% rise on ten is four, and a percentage alone dramatises small numbers into false urgency.

Three numbers, not thirty. A message with a table gets skimmed; one with the three figures somebody would have looked up gets read.

Link to the detail rather than including it, so the message stays short and the person who wants more can get it.

Keep the shape identical every time. A report in the same format each week can be read in three seconds because the reader knows where to look, which is the whole point of sending it on a schedule.

Making it survive

Check the sampling and thresholding metadata on every response and surface it rather than discarding it.

Read the available dimensions from metadata rather than hard-coding, since custom dimensions change.

Handle the empty result deliberately. Zero rows may mean no traffic or a broken filter, and those are opposite situations.

Respect data freshness. A report run at midnight for the day just ended may be incomplete, so run it later or state the caveat.

Report the outcome. Which report ran, over what range, and whether anything was sampled.

Limits worth knowing about

Slack rate limits apply per method, so a report fanning out to many channels needs pacing rather than a loop.

Scheduled runs and data freshness interact. A report run just after midnight for the day just ended will be incomplete, so run it late morning or say that the figure is provisional.

Message formatting is limited. A table that renders acceptably on a desktop is unreadable on a phone, which is where a good share of these are read.

Slack retention is a workspace setting and unrelated to your analytics retention, so the channel is not an archive of your reporting.

Property access is granted per property, so an automation covering several properties needs access to each and will report nothing rather than erroring on the ones it lacks.

A scheduled report that fails silently looks like a quiet week. Whatever runs the schedule should report its own failures somewhere other than the channel it posts to.

What to set up first

Conversion tracking health: an alert when a conversion event stops arriving or falls sharply against its own same-weekday baseline, sent to engineering with the last time it was seen. It is read-only, it takes little building, and it catches the failure that otherwise gets noticed weeks later when somebody wonders why a number looks odd.

Two habits make the difference. Alert on absence as well as decline, since a broken event produces no data rather than a low number. And include the last-seen timestamp, because it usually identifies the release that broke it without anybody having to investigate.

Frequently asked questions

Why does the alert fire every Monday?

Because the baseline is not weekday-aware. Compare against the median of the same weekday over the last few weeks. Web traffic has a strong weekly rhythm, and a flat baseline is wrong twice a week, every week.

Should analytics movements be alerts?

Rarely. Most belong in a scheduled report with a comparison. Reserve alerts for things that are broken — conversions at zero, a source vanished, events stopped — because those need somebody and ordinary variance does not.

Somebody says the number in Slack is wrong — what now?

Check the message carried the caveats: the range, the timezone, and whether the result was sampled. Most of these disputes are about method rather than data, and a message that states its method ends them without anybody opening GA4.

Should the caveats be in every message?

Yes, in the same words and the same place. Caveats that appear occasionally read as new information and cause alarm; identical ones every week become background the reader trusts and stops rereading.

What is the most valuable analytics alert?

A conversion event that has stopped arriving. It produces no error anywhere, it is usually caused by a release, and it is typically found weeks later. Alerting on absence catches it the same day.

Should the daily number go to a channel?

Weekly is usually better, and daily only during a campaign. A daily number that rarely changes meaningfully trains people to skip it, and then they skip the week it mattered.

How many reports should one channel receive?

One, ideally. A channel with the weekly traffic report, a content digest, and campaign updates is a channel where the tracking-broken alert sits unread beneath the other three. Split by audience rather than by topic.

How do I stop people ignoring the weekly report?

Lead with what changed rather than what the level is, keep it to about three numbers, give absolutes alongside percentages, and use an identical format every week so it can be read in seconds. A report people cannot read in one glance gets skipped.

Percentages or absolute numbers?

Both. A percentage on a small base dramatises noise into apparent urgency, and an absolute number without a comparison cannot be interpreted. One sentence carrying both is the format that survives scrutiny.

Should we use GA4's own alerting instead?

GA4's built-in anomaly detection is reasonable and it cannot reach Slack, cannot join your own data, and cannot alert on absence in the way a broken event needs. Use it where it fits and build for the cases it does not cover.

Related reading

• Google Analytics and CodeWords
• Automating Slack alerts from monitoring tools
• CodeWords integrations and templates