Satu atau Terpisah? Strategi Measurement GA4 untuk Domain & Subdomain

Dalam implementasi Google Analytics 4 (GA4), salah satu keputusan arsitektural yang sering dianggap sepele namun berdampak besar adalah: apakah subdomain perlu memiliki measurement (Measurement ID / Data Stream) sendiri atau tidak?

Kesalahan di tahap ini tidak langsung terlihat, tapi efeknya muncul di kemudian hari:

• user count membengkak
• funnel terputus
• conversion attribution salah
• insight jadi dangkal

Artikel ini membahas pendekatan yang benar, trade-off teknisnya, serta best practice nyata di dunia engineering.

Memahami Istilah: Property vs Measurement

Sebelum masuk ke keputusan, kita samakan istilah:

• GA4 Property: wadah utama data analytics
• Measurement ID (G-XXXX): identitas data stream (web/app)
• Subdomain: bagian dari domain yang sama (blog.example.com, app.example.com)

Satu property bisa memiliki banyak measurement, tapi satu measurement hanya mewakili satu stream.

Dua Pendekatan Utama

Pendekatan A — Satu Measurement untuk Semua Subdomain

example.com
blog.example.com
app.example.com
   ↓
G-XXXXXXX

Semua domain & subdomain menggunakan Measurement ID yang sama.

Pendekatan B — Measurement Terpisah per Subdomain

example.com      → G-AAA
blog.example.com → G-BBB
app.example.com  → G-CCC

Setiap subdomain memiliki Measurement ID sendiri.

Pendekatan A: Satu Measurement ID

Kelebihan

User Journey Utuh

GA4 mengidentifikasi user berdasarkan cookie dan device signal. Dengan satu measurement:

• user dari blog → app tetap dihitung 1 user
• session tidak terpecah
• funnel lintas subdomain bisa dianalisis

Ini sangat penting untuk:

• content → signup funnel
• SEO → conversion
• SaaS onboarding

Attribution Lebih Akurat

Traffic source dari blog (organic, referral) tetap terbaca saat user melakukan konversi di app.

Jika measurement dipisah, attribution ini hilang sepenuhnya.

Lebih Sedikit Overhead

• satu konfigurasi
• satu event taxonomy
• satu dashboard

Secara engineering, ini lebih sustainable.

Kekurangan

Data Tercampur

Page view blog dan app berada di dataset yang sama.

Namun ini bisa diatasi dengan:

• hostname
• page_path
• custom dimension

Masalah ini bersifat reporting, bukan arsitektural.

Ownership Tim Kurang Jelas

Jika blog dan app dikelola tim berbeda, perlu effort tambahan untuk membuat report terpisah.

Pendekatan B: Measurement Terpisah

Kelebihan

Data Terisolasi Total

• KPI jelas
• tidak ada noise lintas domain
• cocok untuk multi-produk

Cocok untuk Produk yang Benar-Benar Berbeda

Contoh:

• blog publik
• internal admin tool
• dashboard khusus klien

Dalam kasus ini, memisahkan measurement adalah keputusan yang tepat.

Kekurangan (Kritis)

User & Session Terpecah

GA4 tidak bisa menggabungkan user antar measurement ID.

Dampaknya:

• satu orang dihitung sebagai beberapa user
• retention palsu
• funnel rusak

Conversion Attribution Hilang

Signup di app tidak bisa dikaitkan dengan traffic blog.

Untuk bisnis berbasis funnel, ini fatal.

Over-Engineering

Banyak implementasi memisahkan measurement hanya demi “rapi”.

Hasilnya:

• data sulit dianalisis
• insight minim
• keputusan salah

Decision Matrix

Gunakan tabel ini sebagai panduan praktis:

Best Practice Hybrid (Pendekatan Ideal)

Pendekatan paling sehat di banyak sistem production:

Satu measurement ID, segmentasi di level report

Implementasi:

• satu Measurement ID
• bedakan dengan hostname
• event naming konsisten

Contoh:

hostname = blog.example.com
hostname = app.example.com

Dengan ini, kamu bisa:

• melihat data blog saja
• melihat data app saja
• menganalisis funnel lintas subdomain

Anti-Pattern yang Harus Dihindari

1. ❌ Memisahkan measurement karena “biar rapi”
2. ❌ Memisahkan tanpa memahami user journey
3. ❌ Mengorbankan funnel demi isolasi data

Analytics bukan soal kerapian struktur, tapi kebenaran insight.

Rekomendasi Final

Jika subdomain:

• masih satu ekosistem
• satu user journey
• satu tujuan bisnis

➡️ Gunakan SATU measurement ID

Pisahkan measurement hanya jika:

• produk benar-benar berbeda
• tidak ada funnel lintas domain

Penutup

Kesalahan arsitektur analytics jarang terlihat di awal, tapi mahal di belakang.

Dengan memilih strategi measurement yang tepat sejak awal, kamu memastikan:

• data akurat
• insight bisa dipercaya
• keputusan engineering & bisnis tidak salah arah

Analytics yang baik bukan yang paling rapi, tapi yang paling jujur merepresentasikan perilaku user.