Analytics for the New Site

It's the obvious choice and it's the wrong one as the primary tool. Netlify Analytics is $9/month per site and server-side, which is genuinely nice — ad blockers can't stop it and it needs no cookie consent. But:

• 30-day retention. That's the killer. The Squarespace report we just exported spans 19 months. Netlify gives a rolling month and nothing before it.
• No custom events, goals, or conversion tracking. So it can't tell us a donation happened.
• No year-over-year comparison — the exact view Robert and Jaylene ask for.
• No data export. When you stop paying, the history is gone.

The one thing it's genuinely good for

Netlify's "Top resources not found" report lists real 404s observed server-side — something no JavaScript tool catches reliably, because a browser hitting a dead URL never runs our tag. In the weeks right after a migration that is the single most useful report there is: it tells us which old URLs we failed to redirect.

Recommendation: switch it on for the month around cutover, read the 404 list weekly, add redirects, then switch it off. Roughly $18 total.

Google Tag Manager (GTM-TD3Z4XNG) is already on every public page, installed behind the cookie-consent gate in July 2026. No GA tag is currently firing through it. So this is a container change, not a code change — nothing to deploy.

• Free, with history that doesn't expire at 30 days
• Conversion tracking — required for the Google Ad Grant Robert is considering
• Search Console integration — search queries, which Squarespace never showed us
• Already consent-gated, so it inherits the banner we built

If staff want something simpler to actually read day-to-day, Plausible or Fathom (~$9–14/mo) gives a plain dashboard much closer in spirit to Squarespace's. Optional — GA4 alone meets the requirement.

What was actually wrong

The site loaded GTM-TD3Z4XNG only. That container is Meyer Partners' — it is not in LIM's Tag Manager account, so we cannot edit it. Fetching its gtm.js shows it carries a Universal Analytics reference plus a Feathr hook. UA was retired in July 2023, so nothing on the site was reporting into GA4 at all.

LIM's own container, GTM-TZG3PCB, already held a Google Tag firing on All Pages into G-ZLC3QT9T1E. It had simply never been installed on the site.

The fix

• GTM-TZG3PCB now loads alongside GTM-TD3Z4XNG on all 8 public pages, behind the existing cookie-consent gate. Meyer's container was kept, not replaced — removing it could break their Feathr tracking, which is theirs to speak to.
• Event data retention raised 2 months → 14 months. The 2-month default would have discarded exactly the long-range history we are switching for, and the change is not retroactive.

Still open

• Confirm data is flowing — visit the site, accept cookies, then check GA4 → Reports → Realtime. Nothing arrives before consent is granted, by design.
• Ask Meyer whether GTM-TD3Z4XNG is still needed. If its only live content is a dead UA tag, it is dead weight on every page load.

Step 5 — Link Search Console

GA4 Admin → Product Links → Search Console. This is what surfaces the search queries bringing people in — the single biggest reporting gain over Squarespace.

There is no meaningful downside to installing before cutover, and one real benefit: we find out the tag works while it doesn't matter, rather than discovering it's broken on launch day when traffic actually arrives.

The one caveat, and how to handle it

Until DNS moves, traffic hits lim2026.netlify.app. After it moves, lutheranindianministries.org. Both report into the same property, so the pre-launch weeks will contain our own testing and client review visits — a slightly dirty baseline.

• Filter internal traffic by IP — Admin → Data Streams → Configure tag settings → Define internal traffic. Add the office/home IPs, then activate the Internal Traffic filter (it's created in testing mode by default and does nothing until you switch it to active).
• Segment by hostname when reading reports. GA4 records the hostname, so netlify.app traffic can be excluded from any report or exploration after the fact.
• Write down the cutover date and treat it as the real baseline. Note it in status.html when it happens.

Overlapping with Squarespace for a few weeks is a feature, not a problem — two sources measuring the same period is how we sanity-check that the new numbers are believable before the old ones disappear.

Worth keeping, because it should shape what we build next. Traffic is extraordinarily concentrated — four pages are 62% of all views.

• / — 8,927
• /healing-wounds-of-trauma — 4,802 (3:29 average time on page — the most engaged page on the site)
• /about — 3,332
• /donate — 2,820

The buried finding

"What Do Lutherans Believe?" is the best-performing content after the four main pages — roughly 1,500 views across four posts (sacraments 869, Augsburg Confession 301, confession 222, repentance 142), with 4-minute average read times and 90%+ bounce, which is the signature of people arriving from search, reading, and leaving satisfied.

All four currently redirect to the homepage, and all four are captured in archive/squarespace/posts/. Rebuilding that series and pointing the redirects at the rebuilds is the highest-value content work available right now.

Why homepage redirects matter: Google treats bulk redirects to the homepage as soft 404s — it drops those URLs from the index rather than passing their accumulated value to the new site. Roughly 6,000 views over 19 months currently land that way.

• Create the GA4 property and copy the Measurement ID.
• Set event data retention to 14 months — day one, not later. Not retroactive.
• Add the Google Tag in GTM-TD3Z4XNG, gated on consent. Preview, then Publish.
• Link Search Console to GA4.
• Define and activate internal traffic filtering so our own testing doesn't pollute the baseline.
• Switch on Netlify Analytics for the cutover month and work the 404 report weekly.
• Record the cutover date in status.html as the real baseline.
• Rebuild the "What Do Lutherans Believe?" series from the archive and repoint its redirects.