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 punya Measurement ID sendiri atau cukup berbagi dengan domain utama. Kesalahan di tahap ini tidak langsung terlihat — situs tetap mengirim data, dashboard tetap terisi angka — tapi efeknya muncul perlahan di kemudian hari: user count yang membengkak tidak wajar, funnel yang terputus tanpa sebab jelas, attribution konversi yang salah arah, dan insight yang akhirnya jadi dangkal meski datanya terlihat lengkap. Artikel ini membedah mekanisme di balik kedua pendekatan, trade-off teknisnya secara konkret, serta cara mengimplementasikan pendekatan hybrid yang dipakai banyak sistem production.

Memahami Istilah: Property, Data Stream, Measurement ID

Sebelum masuk ke keputusan, penting menyamakan istilah dan memahami hierarkinya — karena ketiga istilah ini sering dipakai bergantian padahal mewakili tingkatan yang berbeda.

flowchart TD
    A[GA4 Property] --> B[Data Stream: Web]
    A --> C[Data Stream: iOS App]
    A --> D[Data Stream: Android App]
    B --> E[Measurement ID: G-XXXXXXX]
    C --> F[App ID + Stream ID]
    D --> G[App ID + Stream ID]

• GA4 Property adalah wadah utama data analytics — satu property bisa menampung data dari banyak sumber sekaligus
• Data Stream adalah satu sumber data spesifik di dalam property, bisa berupa web, iOS app, atau Android app
• Measurement ID (G-XXXXXXX) adalah identitas unik untuk data stream berjenis web — inilah ID yang ditempel di kode tracking sebuah halaman

Satu property bisa memiliki banyak measurement ID (lewat banyak data stream), tapi satu measurement ID hanya mewakili satu stream tunggal. Keputusan “satu atau terpisah” yang dibahas di artikel ini sebenarnya adalah keputusan tentang berapa banyak data stream web yang dibuat untuk mewakili domain dan subdomain-mu — bukan soal jumlah property.

Bagaimana GA4 Mengidentifikasi User Lintas Subdomain

Klaim bahwa “satu measurement membuat user journey tetap utuh lintas subdomain” sering disebutkan tanpa penjelasan mekanismenya — padahal memahami cara kerja identifikasi user ini adalah kunci untuk benar-benar mengerti kenapa pendekatan ini berdampak besar, bukan sekadar soal kerapian data.

GA4 mengidentifikasi user terutama lewat cookie first-party bernama _ga, yang menyimpan client_id unik per browser. Secara default, cookie ini di-scope ke domain utama (eTLD+1), bukan ke subdomain spesifik tempat ia pertama kali dibuat.

sequenceDiagram
    participant User
    participant Blog as blog.example.com
    participant App as app.example.com
    participant GA4
    User->>Blog: Kunjungi blog
    Blog->>User: Set cookie _ga (scope: .example.com)
    User->>App: Pindah ke app
    App->>User: Baca cookie _ga yang SAMA
    Note over Blog,App: Karena scope cookie di domain utama,<br/>kedua subdomain membaca client_id yang sama
    App->>GA4: Kirim event dengan client_id sama
    Note over GA4: Jika measurement ID SAMA,<br/>GA4 menyatukan ini sebagai 1 user

Inilah mekanisme intinya: cookie _ga memang bisa dibaca lintas subdomain karena scope domainnya memang sengaja diset ke domain utama. Tapi cookie yang sama saja tidak cukup — GA4 baru menyatukan data sebagai satu user kalau event-event itu juga dikirim ke measurement ID yang sama. Kalau blog.example.com mengirim ke G-AAA dan app.example.com mengirim ke G-BBB, meski cookie client_id-nya identik, GA4 memprosesnya sebagai dua property/stream terpisah yang tidak pernah saling tahu soal keberadaan satu sama lain.

Cookie _ga yang ter-share lintas subdomain adalah prasyarat teknis, bukan jaminan otomatis. User journey yang utuh baru benar-benar terjadi kalau prasyarat cookie shared ini dipasangkan dengan measurement ID yang sama di seluruh subdomain yang terlibat.

Dua Pendekatan Utama

flowchart TD
    subgraph A["Pendekatan A: Satu Measurement"]
        A1[example.com]
        A2[blog.example.com]
        A3[app.example.com]
        A1 --> AID[G-XXXXXXX]
        A2 --> AID
        A3 --> AID
    end
    subgraph B["Pendekatan B: Measurement Terpisah"]
        B1[example.com] --> BID1[G-AAA]
        B2[blog.example.com] --> BID2[G-BBB]
        B3[app.example.com] --> BID3[G-CCC]
    end

Pendekatan A — semua domain dan subdomain mengirim event ke Measurement ID yang sama, memanfaatkan mekanisme shared cookie yang sudah dijelaskan di atas secara penuh.

Pendekatan B — setiap subdomain punya Measurement ID sendiri, masing-masing jadi unit data yang sepenuhnya terisolasi satu sama lain meski secara teknis cookie-nya tetap bisa ter-share.

Pendekatan A: Satu Measurement ID

Kelebihan

User journey utuh. Karena mekanisme di bagian sebelumnya — cookie shared + measurement sama — user dari blog yang lanjut ke app tetap dihitung sebagai 1 user, bukan 2. Session tidak terpecah, dan funnel lintas subdomain bisa dianalisis sebagai satu alur utuh. Ini krusial untuk skenario seperti content marketing yang berujung ke signup, optimasi SEO yang berujung ke konversi, atau onboarding SaaS yang melibatkan landing page terpisah dari aplikasi utama.

Attribution lebih akurat. Traffic source dari blog — organic search, referral, sosial media — tetap terbaca utuh saat user akhirnya melakukan konversi di subdomain app. Ini karena GA4 menyimpan informasi acquisition di level user/session yang sama, bukan di level measurement yang terpisah. Kalau measurement dipisah, informasi acquisition awal ini hilang sepenuhnya — konversi di app akan terlihat seolah datang “dari mana saja” alih-alih dari kampanye blog spesifik yang sebenarnya membawa user tersebut.

Lebih sedikit overhead operasional. Satu konfigurasi data stream, satu event taxonomy yang konsisten, satu dashboard sebagai sumber kebenaran. Secara engineering, ini jauh lebih sustainable untuk dipelihara jangka panjang dibanding mengelola banyak property paralel.

Kekurangan

Data tercampur dalam satu dataset. Page view dari blog dan dari app berada di tabel data mentah yang sama. Tapi ini adalah masalah reporting, bukan masalah arsitektural — bisa diatasi sepenuhnya dengan dimension bawaan seperti hostname, page_path, atau custom dimension tambahan (dibahas lebih detail di bagian implementasi hybrid).

Ownership tim kurang jelas. Kalau blog dan app dikelola tim yang sepenuhnya berbeda, dengan satu measurement dibutuhkan effort tambahan untuk membuat laporan tersegmentasi per tim — meski ini juga terselesaikan dengan filter hostname yang konsisten.

Pendekatan B: Measurement Terpisah

Kelebihan

Data terisolasi total. KPI jadi sangat jelas batasannya, tidak ada noise lintas domain yang perlu difilter, dan ini cocok untuk skenario multi-produk yang memang sepenuhnya independen satu sama lain.

Cocok untuk produk yang benar-benar berbeda. Contoh nyata: blog publik, internal admin tool, atau dashboard khusus klien yang masing-masing punya audiens dan tujuan analytics yang sama sekali berbeda. Dalam kasus seperti ini, memisahkan measurement justru adalah keputusan yang tepat — karena memang tidak ada user journey yang realistis menghubungkan ketiganya.

Kekurangan (Kritis)

User dan session terpecah secara teknis, bukan cuma soal pelaporan. Ini bukan keterbatasan konfigurasi yang bisa diakali — GA4 secara arsitektural tidak menggabungkan data antar measurement ID yang berbeda, bahkan jika cookie client_id-nya identik. Setiap measurement memproses event-nya sebagai property yang berdiri sendiri, dengan user_pseudo_id internal yang dihitung dalam konteks property masing-masing. Akibatnya:

• Satu orang yang berpindah dari blog ke app dihitung sebagai dua user berbeda di dua dashboard berbeda
• Metrik retention jadi palsu — sistem tidak tahu bahwa “user baru” di app sebenarnya adalah user lama yang sudah pernah berinteraksi di blog
• Funnel yang melibatkan lebih dari satu subdomain praktis tidak bisa dianalisis sebagai satu alur, karena datanya memang tidak pernah disatukan di level manapun

Conversion attribution hilang sepenuhnya. Signup yang terjadi di app tidak bisa dikaitkan dengan kampanye atau channel traffic yang membawa user itu dari blog. Untuk bisnis yang model pertumbuhannya berbasis funnel — content ke signup, SEO ke konversi — ini bukan kekurangan kecil, melainkan kehilangan kemampuan mengukur apa yang sebenarnya mendorong pertumbuhan.

Over-engineering yang menyamar sebagai kerapian. Banyak implementasi memisahkan measurement hanya karena terasa lebih “rapi” secara struktural, tanpa mempertimbangkan bahwa data analytics yang terpisah secara prematur justru membuat insight makin sulit didapat, bukan makin mudah.

Decision Matrix

Implementasi Hybrid: Satu Measurement + Segmentasi hostname

Pendekatan paling sehat di banyak sistem production bukan memilih salah satu secara ekstrem, melainkan: satu Measurement ID, segmentasi dilakukan di level reporting. Pendekatan ini mempertahankan seluruh keunggulan user journey yang utuh, sambil tetap memungkinkan analisis per subdomain kapan pun dibutuhkan.

Implementasinya memanfaatkan dimension bawaan GA4 bernama hostname, yang otomatis tercatat di setiap event tanpa konfigurasi tambahan apapun — GA4 selalu merekam dari domain/subdomain mana sebuah event dikirim.

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

Cara memakainya dalam praktik, lewat GA4 Explore report:

1. Buat exploration baru di menu Explore
2. Tambahkan dimension Hostname ke dalam laporan
3. Gunakan sebagai filter (misalnya hostname dimulai dengan app.) untuk melihat data app saja
4. Hapus filter untuk melihat funnel lintas subdomain secara utuh

Dengan satu pengaturan ini, kamu mendapat fleksibilitas penuh:

• Melihat data blog saja — filter hostname ke blog.example.com
• Melihat data app saja — filter hostname ke app.example.com
• Menganalisis funnel lintas subdomain — hapus filter, lihat seluruh perjalanan user dari blog sampai konversi di app, sesuatu yang sama sekali tidak mungkin dilakukan kalau measurement dipisah sejak awal

Untuk kebutuhan segmentasi yang lebih spesifik dari sekadar hostname — misalnya membedakan section blog tertentu atau versi app — tambahkan custom dimension event-scoped di GTM atau lewat gtag langsung, lalu daftarkan sebagai custom dimension di GA4. Prinsipnya tetap sama: satu measurement ID, detail tambahan ditangkap lewat dimension, bukan dengan memecah measurement.

Anti-Pattern yang Harus Dihindari

✗ Memisahkan measurement karena "biar terlihat rapi" -- tanpa alasan teknis konkret
✓ Pertahankan satu measurement, gunakan hostname/custom dimension untuk segmentasi

✗ Memisahkan measurement tanpa memetakan user journey lintas subdomain dulu
✓ Petakan dulu: apakah ada funnel realistis yang melewati subdomain ini? Baru putuskan

✗ Mengorbankan integritas funnel demi isolasi data yang "terlihat" lebih bersih
✓ Isolasi data bisa dicapai lewat filter report, tanpa mengorbankan kemampuan analisis funnel

Begitu measurement sudah terlanjur dipisah dan berjalan cukup lama, migrasi ke satu measurement tidak bisa menyatukan data historis yang sudah terlanjur terpecah. Keputusan ini idealnya diambil di awal implementasi, bukan diperbaiki belakangan setelah data production menumpuk di kedua sisi.

Analytics yang baik bukan soal kerapian struktur konfigurasi, melainkan soal kebenaran insight yang bisa dihasilkan dari data itu.

Tabel Ringkasan Trade-off

Ringkasan

• GA4 Property bisa menampung banyak Data Stream, dan setiap Measurement ID mewakili satu stream — keputusan satu vs terpisah sebenarnya soal berapa banyak data stream web yang dibuat.
• Cookie _ga di-scope ke domain utama sehingga bisa dibaca lintas subdomain, tapi user journey baru benar-benar utuh kalau event-eventnya juga dikirim ke Measurement ID yang sama.
• Satu measurement menjaga user journey, session, dan conversion attribution tetap utuh lintas subdomain — krusial untuk funnel content-ke-signup atau SEO-ke-konversi.
• Measurement terpisah cocok untuk produk yang benar-benar independen (admin tool, dashboard klien), tapi memecah user/session secara arsitektural, bukan sekadar soal pelaporan.
• Data yang tercampur di satu measurement adalah masalah reporting yang sepenuhnya bisa diatasi dengan dimension hostname bawaan GA4, tanpa perlu memecah measurement.
• Migrasi dari measurement terpisah ke satu measurement tidak bisa menyatukan data historis yang sudah terlanjur terpecah — putuskan strategi ini di awal implementasi.
• Decision matrix sederhana: pisahkan measurement hanya jika produk benar-benar berbeda dan tidak ada funnel lintas domain; selain itu, satu measurement dengan segmentasi report adalah pilihan paling sehat.