Google Analytics UI এবং BigQuery এক্সপোর্টের মধ্যে ব্যবধান পূরণ করুন

মিনহাজ কাজী , ডেভেলপার অ্যাডভোকেট, গুগল অ্যানালিটিক্স - এপ্রিল 2023


"কিন্তু কেন সংখ্যা UI এর সাথে মিলবে না?"

আপনি যদি আপনার GA4 প্রপার্টির জন্য BigQuery ইভেন্ট এক্সপোর্ট ডেটা নিয়ে কাজ করে থাকেন, তাহলে আপনি অবশ্যই কোনো সময়ে এই প্রশ্নটি করেছেন। বা আরও খারাপ - অন্য কেউ আপনাকে এটি জিজ্ঞাসা করেছে। এবং এটির উত্তর দেওয়ার চেষ্টা করার সময়, আপনাকে সম্ভবত ভয়ঙ্কর ফলোআপ প্রশ্ন জিজ্ঞাসা করা হয়েছে:

"এবং এটি কোথায় বলে?"

এই পোস্টের মাধ্যমে, আমরা উভয়ের উপর আলোকপাত করার চেষ্টা করব।

সংখ্যাগুলি কীভাবে পরিবর্তিত হয় তার বিশদ বিবরণে যাওয়ার আগে, BigQuery ইভেন্ট এক্সপোর্ট ডেটার উদ্দেশ্যটি বোঝা গুরুত্বপূর্ণ। Google Analytics ব্যবহারকারীরা তাদের সংগৃহীত ডেটা সংগ্রহের পদ্ধতিগুলির মধ্যে একটির মাধ্যমে GA-তে পাঠায় - Google Tag , Google Tag Manager , Measurement Protocol , SDKs , এবং Data Import । GA প্রপার্টির সেটিংসের উপর ভিত্তি করে, Google Analytics স্ট্যান্ডার্ড রিপোর্ট , এক্সপ্লোরেশন এবং ডেটা এপিআই সহ স্ট্যান্ডার্ড রিপোর্টিং সারফেসে পৌঁছানোর আগে সংগৃহীত ডেটাতে উল্লেখযোগ্য মূল্য সংযোজন করে। এই মূল্য সংযোজনগুলির মধ্যে Google সংকেত, মডেলিং, ট্রাফিক অ্যাট্রিবিউশন, পূর্বাভাস ইত্যাদি অন্তর্ভুক্ত থাকতে পারে।

স্ট্যান্ডার্ড রিপোর্টিং পৃষ্ঠতলের লক্ষ্য হল সর্বনিম্ন ঘর্ষণে GA ব্যবহারকারীদের সর্বোচ্চ মান প্রদান করা। যাইহোক, আমরা বুঝতে পারি যে ব্যবহারকারীদের বিস্তৃত বর্ণালীতে, কেউ কেউ Google Analytics দ্বারা মূল্য সংযোজন পরিপূরক করতে বা এমনকি সম্পূর্ণ কাস্টমাইজড কিছু করতে চাইতে পারে। এই ব্যবহারকারীদের জন্য, BigQuery ইভেন্ট এক্সপোর্ট হল উদ্দিষ্ট সূচনা পয়েন্ট। BigQuery ইভেন্ট এক্সপোর্টে ডেটা সংগ্রহ করা হবে, যা ক্লায়েন্ট বা অ্যাপ থেকে Google Analytics-এ পাঠানো হয়। BigQuery ইভেন্ট এক্সপোর্টে উপরে উল্লিখিত বেশিরভাগ মূল্য সংযোজনে দানাদার ডেটা থাকবে না।

এইভাবে, বিপুল সংখ্যক ব্যবহারের ক্ষেত্রে, স্ট্যান্ডার্ড রিপোর্টিং সারফেস এবং BigQuery রপ্তানি ডেটা এই মান সংযোজন অংশগুলির ক্ষেত্রে মিলিত হবে বলে আশা করা যায় না। যদি উভয়ের মধ্যে অভ্যন্তরীণ সামঞ্জস্য থাকে এবং আপনি যা সংগ্রহ করছেন তার সাথে সেগুলি মিলে যায়, তাহলে আপনার যেতে হবে।

এখন আসুন পার্থক্যের জন্য কিছু নির্দিষ্ট কারণের মধ্যে প্রবেশ করি এবং সম্ভব হলে সেগুলি হ্রাস করার উপায়গুলি অন্বেষণ করি। এই পোস্টটি শুধুমাত্র BigQuery দৈনিক ইভেন্ট এক্সপোর্টের উপর ফোকাস করে এবং স্ট্রিমিং এক্সপোর্ট নয়।

স্যাম্পলিং

স্ট্যান্ডার্ড রিপোর্ট, ডেটা API রিপোর্ট বা এক্সপ্লোরেশন রিপোর্টের সাথে আপনার BigQuery এক্সপোর্ট ডেটার সঠিক তুলনা করার জন্য নিশ্চিত করুন যে সেগুলি নমুনা করা ডেটার উপর ভিত্তি করে নয়। GA4-এ ডেটা স্যাম্পলিং আরও বিশদ বিবরণ এবং নমুনা নেওয়ার উপায় প্রদান করে।

সক্রিয় ব্যবহারকারী

আপনি যদি আপনার GA4 প্রপার্টিতে অন্তত একটি ইভেন্টে লগ করা সমস্ত ব্যবহারকারীকে গণনা করেন, তাহলে আপনি মোট ব্যবহারকারীর মেট্রিক পাবেন। যদিও GA4 UI-এর অনুসন্ধানে মোট ব্যবহারকারীর মেট্রিক পাওয়া যায়, তবে GA4-এ রিপোর্ট করার জন্য ব্যবহৃত প্রাথমিক ব্যবহারকারী মেট্রিক হল সক্রিয় ব্যবহারকারী । GA4 UI এবং রিপোর্টে, শুধুমাত্র ব্যবহারকারীদের উল্লেখ করা থাকলে, এটি সাধারণত সক্রিয় ব্যবহারকারীদের বোঝায়। তাই BigQuery ডেটা থেকে ব্যবহারকারীর সংখ্যা গণনা করার সময়, আপনাকে GA UI-এর সাথে তুলনীয় সংখ্যা তৈরি করতে শুধুমাত্র সক্রিয় ব্যবহারকারীদের ফিল্টার করতে হবে এবং রাখতে হবে। আপনার নির্বাচিত রিপোর্টিং আইডেন্টিটির উপর ভিত্তি করে গণনার পদ্ধতিও পরিবর্তিত হবে।

প্রযুক্তিগত বাস্তবায়ন

BigQuery ইভেন্ট এক্সপোর্ট ডেটাতে, আপনি স্বতন্ত্র ব্যবহারকারী আইডির সংখ্যা গণনা করলে, আপনি মোট ব্যবহারকারীর সংখ্যা পাবেন। এখানে একটি নমুনা প্রশ্ন যা user_pseudo_id এর উপর ভিত্তি করে মোট ব্যবহারকারী এবং নতুন ব্যবহারকারী উভয়ই দেখায়:

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

শুধুমাত্র সক্রিয় ব্যবহারকারীদের নির্বাচন করতে, আপনার ক্যোয়ারী ইভেন্টগুলিতে সীমাবদ্ধ করুন যেখানে is_active_user true :

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

হাইপারলগলগ++

সক্রিয় ব্যবহারকারী এবং সেশন সহ সাধারণ মেট্রিকগুলির জন্য কার্ডিনালিটি অনুমান করতে Google Analytics HyperLogLog++ (HLL++) অ্যালগরিদম ব্যবহার করে। এর মানে হল আপনি যখন UI তে বা API-এর মাধ্যমে এই মেট্রিকগুলির অনন্য গণনা দেখেন, তখন সেগুলি একটি নির্দিষ্ট নির্ভুলতার সাথে একটি অনুমান। BigQuery-এ, যেহেতু আপনার কাছে দানাদার ডেটা অ্যাক্সেস আছে, তাই আপনি এই মেট্রিকগুলির জন্য সঠিক কার্ডিনালিটি গণনা করতে পারেন। তাই মেট্রিক্স একটি ছোট শতাংশ দ্বারা পরিবর্তিত হতে পারে. 95% আত্মবিশ্বাসের ব্যবধানে, সেশন গণনার জন্য নির্ভুলতা ±1.63% হতে পারে। নির্ভুলতা মাত্রা বিভিন্ন মেট্রিক্সের জন্য পরিবর্তিত হবে এবং আত্মবিশ্বাসের ব্যবধান অনুযায়ী পরিবর্তিত হবে। HLL++ এর বিভিন্ন নির্ভুলতা পরামিতির জন্য বিভিন্ন আত্মবিশ্বাসের ব্যবধানে নির্ভুলতা স্তরের জন্য HLL++ স্কেচগুলি দেখুন।

প্রযুক্তিগত বাস্তবায়ন

Google Analytics-এ HLL++ কীভাবে প্রয়োগ করা হয়েছে এবং আপনি BigQuery কোয়েরি ব্যবহার করে কীভাবে কার্যকারিতা প্রতিলিপি করতে পারেন তা বোঝার জন্য Google Analytics-এ অনন্য গণনা অনুমান দেখুন।

তথ্য সংগ্রহ বিলম্ব

GA দিনের সমস্ত ইভেন্ট সংগ্রহ করার পরে দৈনিক রপ্তানি টেবিল তৈরি করা হয়। দৈনিক টেবিলগুলি টেবিলের তারিখের পরে 72 ঘন্টা পর্যন্ত আপডেট করা যেতে পারে যে ইভেন্টগুলি টেবিলের তারিখের সাথে সময়-স্ট্যাম্প করা হয়। এই সম্পর্কে বিস্তারিত পড়ুন এবং উদাহরণ দেখুন . যদি আপনার Firebase SDK বা পরিমাপ প্রোটোকল বাস্তবায়ন অফলাইনে বা বিলম্বিত ইভেন্টে পাঠায় তবে এটি একটি সমস্যা। স্ট্যান্ডার্ড রিপোর্টিং সারফেস এবং BigQuery 72 ঘন্টার মধ্যে কখন আপডেট করা হয় তার উপর নির্ভর করে, আপনি তাদের মধ্যে পার্থক্য দেখতে পারেন। এই ধরনের বাস্তবায়নের জন্য, 72 ঘন্টার বেশি পুরানো ডেটার সাথে তুলনা করা উচিত।

উচ্চ কার্ডিনালিটি রিপোর্ট

ধরে নিন আপনি স্ট্যান্ডার্ড রিপোর্ট বা ডেটা API এর মাধ্যমে একটি রিপোর্ট দেখছেন। প্রতিবেদনটি প্রচুর পরিমাণে ডেটা প্রকাশ করে এবং উচ্চ কার্ডিনালিটি সহ মাত্রা রয়েছে৷ উচ্চ কার্ডিনালিটি ডাইমেনশনের কারণে রিপোর্টটি অন্তর্নিহিত টেবিলের জন্য কার্ডিনালিটি সীমা অতিক্রম করতে পারে। যখন এটি ঘটবে, Google Analytics কম ঘন ঘন মানগুলিকে গোষ্ঠীবদ্ধ করবে এবং সেগুলিকে (অন্যান্য) হিসাবে লেবেল করবে৷

একটি সরলীকৃত এবং ছোট স্কেল উদাহরণ ব্যবহার করে, যদি অন্তর্নিহিত সারণির জন্য কার্ডিনালিটি সীমা 10 সারি হয়, তাহলে আপনি যা ঘটতে পারেন তা হল:

Simplified example for Ground-truth data vs Aggregate table with other row

আপনি দেখতে পাচ্ছেন, ইভেন্টের মোট সংখ্যা অপরিবর্তিত রয়েছে। যাইহোক, কম ঘন ঘন মানগুলি একসাথে গোষ্ঠীভুক্ত হয় এবং আপনি যেকোন মাত্রার উপর ভিত্তি করে টেবিলটি পুনরায় একত্রিত করতে পারবেন না (যেমন আপনি সমষ্টি টেবিলটি নিতে পারবেন না এবং উচ্চ নির্ভুলতার সাথে একটি নির্দিষ্ট শহরের জন্য মোট ইভেন্ট গণনা বের করতে পারবেন না)। আপনি যদি যেকোন মাত্রার উপর ভিত্তি করে সামগ্রিক ডেটা ফিল্টার করেন তাহলে উদাহরণটি আরও গভীর হয়।

(অন্যান্য) সারির এই গ্রুপিং শুধুমাত্র রিপোর্টিং মডিউল এবং ডেটা API-তে ঘটে যখন রিপোর্ট কার্ডিনালিটি সীমা অতিক্রম করে। আপনি যদি BigQuery থেকে আপনার গণনা করেন, তাহলে আপনি সর্বদাই গ্রাউন্ড-ট্রুথ ডেটা পাবেন - সবচেয়ে দানাদার সারি। (অন্যান্য) সারি সম্পর্কে আরও পড়ুন এবং কীভাবে এটি এড়ানো যায় তার সেরা অনুশীলনগুলি পড়ুন।

গুগল সিগন্যাল

আপনার GA4 প্রপার্টিতে Google সিগন্যাল অ্যাক্টিভেট করার ফলে বিভিন্ন প্ল্যাটফর্ম এবং ডিভাইস জুড়ে ব্যবহারকারীদের অনুলিপি করা সহ বিভিন্ন সুবিধা রয়েছে। আপনি যদি ব্যবহারকারীর আইডি সংগ্রহ না করেন বা Google সিগন্যাল সক্রিয় না করেন এবং একজন ব্যক্তি আপনার ওয়েবসাইটটি তিনটি ভিন্ন ওয়েব ব্রাউজারে দেখেন, তাহলে Google Analytics তিনটি ভিন্ন ব্যবহারকারীকে সেই ক্রিয়াকলাপটিকে দায়ী করে এবং BigQuery এক্সপোর্টে তিনটি পৃথক user_pseudo_id থাকবে। বিপরীতে, Google সিগন্যাল সক্রিয় হওয়ার সাথে সাথে এবং ব্যক্তি তিনটি ব্রাউজারে তাদের একক Google অ্যাকাউন্টে লগ ইন করেছে, Google Analytics সেই কার্যকলাপটিকে একজন ব্যবহারকারীর জন্য দায়ী করে এবং স্ট্যান্ডার্ড রিপোর্টিং সারফেসে সেই গণনাকে প্রতিফলিত করে। যাইহোক, BigQuery এখনও তিনটি আলাদা user_pseudo_id দেখাবে কারণ BigQuery এক্সপোর্টে Google সিগন্যালের তথ্য পাওয়া যায় না। এইভাবে, BigQuery এক্সপোর্টের তুলনায় Google সিগন্যাল ডেটা সহ রিপোর্টে সম্ভবত কম ব্যবহারকারীর সংখ্যা থাকবে।

এই প্রভাব কমানোর সর্বোত্তম উপায় হল Google সিগন্যাল সক্রিয় করার সাথে আপনার GA4 প্রপার্টিতে User-IDs প্রয়োগ করা । এটি নিশ্চিত করবে যে user_id উপর ভিত্তি করে প্রথমে অনুলিপিটি ঘটবে। সাইন ইন করা ব্যবহারকারীদের জন্য, user_id ক্ষেত্রটি BigQuery-এ পপুলেট করা হবে এবং গণনার উদ্দেশ্যে ব্যবহার করা যেতে পারে। যাইহোক, যে ব্যবহারকারীরা সাইন ইন করেননি (অর্থাৎ user_id ছাড়া সেশন) তাদের জন্য Google Signals এখনও ডিডপ্লিকেশনের জন্য ব্যবহার করা হবে।

এছাড়াও মনে রাখবেন যে স্ট্যান্ডার্ড রিপোর্টিং সারফেসগুলিতে কিছু রিপোর্টে থ্রেশহোল্ডিং প্রয়োগ করা হতে পারে এবং নির্দিষ্ট ডেটা ফেরত দেয় না। বেশিরভাগ তথ্য যা থ্রেশহোল্ডিং সাপেক্ষে হতে পারে সাধারণত BigQuery এক্সপোর্টে পাওয়া যায় না।

ওয়েবসাইট এবং মোবাইল অ্যাপে সম্মতি মোড আপনাকে আপনার ব্যবহারকারীদের কুকি বা অ্যাপ শনাক্তকারীর সম্মতির স্থিতি Google-এর সাথে যোগাযোগ করতে দেয়। দর্শকরা সম্মতি অস্বীকার করলে, GA4 মূল ইভেন্ট মডেলিং এবং আচরণগত মডেলিং দিয়ে ডেটা সংগ্রহের ফাঁক পূরণ করে। BigQuery ইভেন্ট এক্সপোর্টে মডেল করা ডেটার কোনোটিই পাওয়া যায় না। সম্মতি মোড প্রয়োগ করা হলে, BigQuery ডেটাসেটে GA দ্বারা সংগৃহীত কুকিলেস পিংস থাকবে এবং প্রতিটি সেশনে আলাদা user_pseudo_id থাকবে। মডেলিংয়ের কারণে, BigQuery-এ স্ট্যান্ডার্ড রিপোর্টিং সারফেস এবং গ্রানুলার ডেটার মধ্যে পার্থক্য থাকবে। উদাহরণস্বরূপ, আচরণগত মডেলিংয়ের কারণে, আপনি BigQuery এক্সপোর্টের তুলনায় কম সক্রিয় ব্যবহারকারী দেখতে পাবেন কারণ মডেলিং পৃথক সম্মতিহীন ব্যবহারকারীদের একাধিক সেশনের পূর্বাভাস দেওয়ার চেষ্টা করতে পারে।

আবার, এর প্রভাব কমাতে, আপনার GA4 প্রপার্টিতে User-IDs প্রয়োগ করা উচিত। user_id এবং কাস্টম মাত্রা আপনার ব্যবহারকারীদের সম্মতির স্থিতি নির্বিশেষে BigQuery-এ রপ্তানি করা হয়।

ট্রাফিক অ্যাট্রিবিউশন ডেটা

BigQuery ট্রাফিক অ্যাট্রিবিউশন ডেটা ব্যবহারকারী (প্রথম দর্শন) এবং ইভেন্ট স্তরে উপলব্ধ। এগুলো সংগৃহীত তথ্য। যাইহোক, যেহেতু Google Analytics সেশন লেভেলে তার নিজস্ব অ্যাট্রিবিউশন মডেল প্রয়োগ করে, তাই সেই তথ্যটি BigQuery এক্সপোর্টে সরাসরি পাওয়া যায় না বা উপলব্ধ ডেটার সাথে সম্পূর্ণ নির্ভুলতার সাথে গণনা করা যায় না। আপনার ব্যবহারের ক্ষেত্রে নির্ভর করে, আপনি প্রাসঙ্গিক প্রথম পক্ষের ডেটা সহ BigQuery ডেটাসেটে যোগদান এবং আপনার নিজস্ব অ্যাট্রিবিউশন মডেল তৈরি করার কথা বিবেচনা করতে পারেন। ভবিষ্যতে, BigQuery ইভেন্ট এক্সপোর্টের মাধ্যমে ট্রাফিক অ্যাট্রিবিউশনের জন্য অতিরিক্ত সংগৃহীত ডেটা পাওয়া যেতে পারে।

সাধারণ গণনার ত্রুটি

  • গণনার পদ্ধতি: BigQuery-এ বিভিন্ন মেট্রিক গণনা করার সময়, নিশ্চিত করুন যে আপনি সঠিক পদ্ধতি ব্যবহার করছেন। উদাহরণ স্বরূপ:
    • Google Analytics 4 বৈশিষ্ট্যের জন্য সেশন গণনার আদর্শ পদ্ধতি হল user_pseudo_id / user_id এবং ga_session_id এর অনন্য সমন্বয় গণনা করা, সময়সীমা নির্বিশেষে। ইউনিভার্সাল অ্যানালিটিক্সে, মধ্যরাতে সেশন রিসেট হবে। আপনি যদি UA মডেল অনুসরণ করেন, প্রতিটি দিনের জন্য সেশন গণনা করেন এবং মোট সেশন গণনা পেতে সেগুলি যোগ করেন, আপনি একাধিক দিন জুড়ে থাকা সেশনগুলিকে দ্বিগুণ গণনা করবেন।
    • আপনার নির্বাচিত রিপোর্টিং পরিচয়ের উপর নির্ভর করে, ব্যবহারকারী গণনা গণনা পদ্ধতি আপডেট করতে হবে।
  • মাত্রা এবং মেট্রিক সুযোগ : নিশ্চিত করুন যে আপনার গণনা সঠিক ব্যবহারকারী, সেশন, আইটেম, বা ইভেন্ট স্তরের সুযোগ ব্যবহার করে।
  • টাইম জোন : BigQuery এক্সপোর্টে, event_date হল রিপোর্টিং টাইম জোনের জন্য যেখানে event_timestamp হল মাইক্রোসেকেন্ডে একটি UTC টাইমস্ট্যাম্প। তাই আদর্শভাবে, যদি কেউ একটি প্রশ্নে event_timestamp ব্যবহার করে, UI নম্বরগুলির সাথে তুলনা করার সময় এটি সঠিক প্রতিবেদনের সময় অঞ্চলের জন্য সামঞ্জস্য করতে হবে।
  • ডেটা ফিল্টারিং এবং রপ্তানির সীমা : আপনি যদি আপনার BigQuery ইভেন্ট রপ্তানির জন্য ডেটা ফিল্টারিং সেট আপ করে থাকেন বা আপনার দৈনিক ইভেন্ট রপ্তানির পরিমাণ সীমা ছাড়িয়ে যায়, তাহলে BigQuery ইভেন্ট রপ্তানি ডেটা স্ট্যান্ডার্ড রিপোর্টিং পৃষ্ঠের সাথে মিলবে না।

যে সব সঙ্গে, এই পোস্টে UNNEST করার জন্য একটি বিট আছে. আশা করি আপনি এখানকার নির্দেশিকা থেকে আপনার আলাদা প্রকল্পের জন্য সঠিক সমাধান নির্বাচন করতে পারবেন। আপনার যদি প্রশ্ন থাকে, GA Discord সার্ভারে যোগ দিন যেখানে প্রশ্নগুলিকে স্বাগত জানাই!

পূর্ববর্তী
ব্যবসায়িক সমাধান, ব্যবসায়িক সমাধান
পরবর্তী
HLL++ এর সাথে অনন্য গণনা আনুমানিক