알랭드보통사람

브레이즈 커넥티드 컨텐츠(Connected Content)로 활용할 API 만들기 (feat. Google Cloud Platform)

알랭드보통 사람 — Thu, 23 Jan 2025 12:04:58 +0900

이전 글에서 RFM Segment 라벨링을 빅쿼리에 적재하는 방법을 소개했었습니다.

태블로 Rest API 로 view 데이터 csv 로 다운받고 빅쿼리에 저장하기

태블로에서 RFM 대시보드를 만들고 이를 활용해서 CRM 캠페인 액션들을 수행한뒤 유져벌 RFM 세그먼트 이동을 관찰해야 한다. 하지만 이를 정기적으로 다운로드 받아서 구글 시트에 저장해야하는

botongsaram.tistory.com

RFM 점수에 따라 세그멘트를 분류하면 아래와 같이 유저별로 이렇게 세그먼트 라벨이 생성됩니다.

이 데이터를 브레이즈 커넥티드 콘텐츠로 활용할 수 있게 만들면 효율적이겠다는 판단이 들었습니다.

구글링을 해보니 비개발자도 손쉽게(?) 구현 가능하겠다는 판단이 들어서 API를 만드는 방법을 소개하려고 합니다.

user_id	RFM_Segment_nm	created_at(데이터 적재일)
a	이탈한 고객	2025-01-01
b	떠날 위험이 큰 고객	2025-01-01
c	충성 고객	2025-01-01
d	로열티 가망 고객	2025-01-01
e	신규 고객	2025-01-01
...	...	2025-01-01

브레이즈 커넥티드 컨텐츠란?
외부 서버에 있는 정보를 API로 가져와서 메시지에 활용하는 기능입니다.
브레이즈에 데이터가 저장되지 않아 DP 소진이 안 되는 장점도 있다고 합니다.

커넥티드 컨텐츠는 GET / POST 방식 둘 다 사용 가능하고 이번에 만들어 볼 API는 GET 요청의 형식입니다.

GET / POST 란?
GET / POST 는 HTTP 메서드로 클라이언트에서 서버로 뭔가 요청할 때 사용합니다.

그럼 HTTP 메서드는 뭐냐?
클라이언트가 서버에 요청의 목적 / 종류를 알리는 수단입니다.
아 안에는 GET, POST, PUT, PATCH, DELETE, HEAD, OPTION, CONNECT로 8가지가 있지만
여기선 GET/POST 만 알면 될 것 같습니다.

	GET 방식	POST 방식
사용 목적	서버에 리소스 요청	서버에 리소스 생성 / 업데이트 할 때
DB로 표현하면	SELECT	CREATE
Body 유무	없음	있음

이제 본격적으로 구현해봅시다.

Cloud Function 이 빅쿼리를 쿼리해서 데이터를 반환하는 API를 만드는 과정이라고 보시면 됩니다.

일단 GCP 에 가서 서비스 계정 2개를 만들 겁니다

하나는 API 게이트웨이 만들 때 사용하고 다른 하나는 Cloud Functions을 만들 때 쓸 겁니다.

API 게이트웨이란?
클라이언트가 서버와의 소통하는 다리 역할 (API가 지나다니는 통로!)

서비스 계정 2개 만들기

서비스 계정 2개 생성하기

그리고 각 계정 생성 시 권한을 아래와 같이 부여합니다

	권한
API Gateway 에 사용할 계정	Cloud Functions 호출자
Cloud Functions 에 사용할 계정	BigQuery 읽기 세션 사용자 BigQuery 작업 사용자

그리고 추가로 Cloud Functions에 사용할 계정에 BigQuery에서 조회할 특정 테이블만 권한을 부여해 줍니다.

공유 → 새 주 구성원에 Cloud Functions에 사용할 계정(~~~@iam.gserviceaccount.com~~~)을 추가하고 아래와 같이 BigQuery 데이터 뷰어 권한으로 설정해 주세요.

Cloud Functions 만들기

Cloud Functions에서 함수 만들기를 누르고 아래와 같이 설정합니다.

환경은 1세대(2세대도 상관없으나.. ) 나머지는 이미지 내 설정대로 하고 아래 런타임 서비스 계정을 이전 단계에서 생성한 서비스 계정 중 Cloud Functions에 사용할 계정을 선택해줘야 합니다

그다음 이제 코드를 작성합니다.

코드 동작은 HTTP 요청을 받아 BigQuery 쿼리를 실행하고, 결과를 JSON 형태로 반환하는 코드입니다.

requirement.txt 에는 아래 3가지 라이브러리만 있으면 됩니다.

google-cloud-bigquery
google-cloud-storage
pandas

함수를 생성할 때 진입점을 꼭 기재해 주셔야 동작을 합니다

from google.cloud import bigquery
import json
from datetime import date, datetime

def bigquery_to_api(request):
    try:
        print("Request received.")  # 요청 수신 로그

        # BigQuery 클라이언트 생성
        client = bigquery.Client()
        print("BigQuery client created.")  # 클라이언트 생성 로그

        # 쿼리 작성
        query = """
            SELECT cust_id, rfm_seg_nm 
            FROM `{테이블명}`
            WHERE created_at = (
                SELECT MAX(created_at)
                FROM `{테이블명}`
            )
        """
        print(f"Query to be executed: {query}")  # 쿼리 출력

        # 쿼리 실행
        query_job = client.query(query)
        print("Query executed. Waiting for results...")  # 쿼리 실행 로그

        # 쿼리 결과 가져오기
        results = query_job.result()
        print("Query results fetched.")  # 결과 가져오기 로그

        # JSON 직렬화 가능한 형식으로 변환
        def serialize_row(row):
            return {
                key: (value.isoformat() if isinstance(value, (date, datetime)) else value)
                for key, value in dict(row).items()
            }

        rows = [serialize_row(row) for row in results]

        # 가져온 결과 중 일부만 출력
        sample_rows = rows[:10]  # 최대 10개만 샘플로 출력
        print(f"Number of rows fetched: {len(rows)}")  # 전체 결과 개수
        print(f"Sample rows: {json.dumps(sample_rows, indent=2)}")  # 샘플 결과 출력

        return json.dumps(rows), 200, {'Content-Type': 'application/json'}
    except Exception as e:
        # 예외 처리 및 에러 로그 출력
        print(f"Error occurred: {str(e)}")
        return json.dumps({'error': str(e)}), 500, {'Content-Type': 'application/json'}

API Config 파일 만들기

이제 API을 실행을 위한 yaml 파일을 만들어 줘야 합니다.

이 파일의 역할은 Google Cloud API Gateway에서 API를 정의하고 설정하기 위해 사용됩니다.

API 요청을 클라이언트로부터 수신해서 Cloud Functions로 전달하는 게이트웨이를 구성한다고 생각하시면 됩니다.

또한 이 파일에서 API의 요청 방식(GET / POST)을 정의해 줍니다.

sublime text 하나 여시고 로컬에 저장(아래 코드)하고 API Gateway에 업로드해줍니다.

여기서 address는 앞에서 만든 Cloud Function의 트리거 URL을 복사에서 붙여 줍니다.

아래 파일제목의 확장자는. yaml로 저장해 줍니다.

swagger: "2.0"
info:
  title: "test_rfm_api"
  description: "API 설명"
  version: "1.0.0"
paths:
  /rfm_api: -- 위에서 만들었던 클라우드 함수 이름
    get:
      summary: "Get RFM data from BigQuery"
      description: "Returns Recent BigQuery data."
      operationId: "getRFMData"
      parameters:
        - name: "x-api-key"
          in: "header"
          required: true
          type: "string"
      responses:
        "200":
          description: "Successful response"
          schema:
            type: "array"
            items:
              type: "object"
              properties:
                field_name:
                  type: "string"
      x-google-backend:
        address: "https://asia-northeast3-{프로젝트ID}.cloudfunctions.net/rfm_api"
        protocol: "http/1.1"
      security:
        - api_key: []
securityDefinitions:
  api_key:
    type: "apiKey"
    name: "x-api-key"
    in: "header"

이제 GCP 콘솔에서 API Gateway를 검색해서 게이트웨이를 만듭니다.

아래 API 사양 업로드에 바로 직전에 생성한 yaml 파일을 업로드하고 아래 서비스 계정 선택에서 처음에 생성한 계정 중 API Gateway에 사용할 계정을 선택해 줍니다.

이제 마지막 단계

API 키 만들기

콘솔에서 API 및 서비스를 검색합니다.

API 키를 만들어 줍니다.

생성 후에 API 키를 복사합니다.

아래 설정 중에 'API 제한 설정'이 있는데 API Gateway 설정해 줍니다.

드디어 API 호출!

터미널에서 아래와 같이 입력하면 이렇게 데이터가 출력됩니다!

curl -X GET \
-H "x-api-key: {api_key}" \
"https://{위에서 만든 게이트 웨이 URL}/rfm_api"

{위에서 만든 게이트웨이 URL}/{.yaml파일내 path값}

api 호출 결과

참고글

https://cloud.google.com/api-gateway/docs/creating-api-config?hl=ko

API 구성 만들기 | API Gateway Documentation | Google Cloud

의견 보내기 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. API 구성 만들기 기본 요건 API 구성을 만들려면 먼저 다음을 확인합니다. API 구성 ID 요구사항 아

cloud.google.com

https://zoe1.medium.com/how-to-set-up-an-api-with-a-cloud-function-backend-that-queries-bigquery-on-gcp-5e3f88b508f6

How to set up an API with a Cloud Function backend that queries BigQuery on GCP

This article will show you how to create an API with API Gateway with a Cloud Functions backend that takes in a date in the API query and…

zoe1.medium.com

태블로 Rest API 로 view 데이터 csv 로 다운받고 빅쿼리에 저장하기

알랭드보통 사람 — Sun, 19 Jan 2025 16:12:24 +0900

태블로에서 RFM 대시보드를 만들고 이를 활용해서 CRM 캠페인 액션들을 수행한뒤 유져벌 RFM 세그먼트 이동을 관찰해야 한다.

하지만 이를 정기적으로 다운로드 받아서 구글 시트에 저장해야하는 번거로움이 있다.

반복적인 업무기 때문에 자동화시킬 필요가 있다고 생각하여 구현해본 케이스를 기록도 해볼겸 공유해볼까 한다.

RFM Dashboard

구글링을 해보니 유저 아이디별 라벨링된 세그먼트명을 태블로 RestAPI 를 활용해서 csv 파일로 다운 받을 수 있다.

아주 다행스럽게 파이썬 라이브러리가 있었다.

https://github.com/divinorum-webb/tableau-api-lib

GitHub - divinorum-webb/tableau-api-lib: An API library that allows developers to call on the methods listed in Tableau's REST A

An API library that allows developers to call on the methods listed in Tableau's REST API documentation. - divinorum-webb/tableau-api-lib

github.com

그러면 매번 다운로드해서 관리하지 않아도 정기적으로 RFM 세그먼트의 히스토리 데이터를 적재할 수 있게되고 더불어 이 데이터를 API로 만들어서 Braze에서 쓸 수 있게되면 금상첨화!

구현해보는 걸 나눠서 기록해보려 한다.

다음 글에서는 GCP에서 빅쿼리를 쿼리하는 Cloud Function 로 API를 구현하는 방법을 포스팅 해볼 예정이다.

GCP를 활용했고 구현을 위한 프로세스는 아래와 같다.

일단 Cloud Functions을 2개를 만든다.

하나는 Tableau Rest API 로 데이터를 소싱하는 함수하나 다른 하나는 Cloud Storage에 적재된 CSV 파일을 빅쿼리에 적재하는 함수다.

1. 클라우드 스케줄러로 데이터를 소싱할 시간을 지정해서 Pub/Sub 메시지를 예약.

2. Pub/Sub 메시지로 Cloud Functions을 호출.

3. 함수가 호출되면 데이터를 CSV 로 추출해서 GCS(Cloud Storage)에 적재한다. (그냥 빅쿼리에 바로 적재해도 되지만 혹시 모르니 파일로 저장해둔다.)

4. csv 파일이 GCS에 저장되면 빅쿼리에 데이터를 적재하는 함수를 트리거 시킨다.

5. 빅쿼리에 적재한다.

이렇게 되면 지정한 시간대로 유저별 세그먼트 라벨이 빅쿼리에 적재되게 된다. 히스토리 데이터로 저장되니 이걸 시각화하면 세그먼트의 변화량을 관찰할 수 있게 된다

우선 GCS에 태블로의 view를 csv 파일로 저장하는 코드는 아래와 같다

Cloud Storage 에 Bucket 은 미리 만들어 두고 함수를 만드시길!

import os
from datetime import datetime
from io import BytesIO
import pandas as pd
from google.cloud import storage
from tableau_api_lib import TableauServerConnection
from config import settings

bucket_name = 'bucket_rfm_history'
blob_name = f"rfm_stat_{datetime.now().strftime('%Y-%m-%d')}.csv"

def save_csv_to_gcs(csv_data):
    """
    Cloud Storage에 CSV 데이터를 저장합니다.
    기존 blob이 존재하더라도 새 데이터로 덮어씁니다.
    """
    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(blob_name)

    print(f"Saving latest data to '{bucket_name}/{blob_name}'...")
    blob.upload_from_string(csv_data, content_type='text/csv')
    print(f"Data saved successfully to '{bucket_name}/{blob_name}'.")

def format_date_columns(df):
    """
    날짜 컬럼의 형식을 'YYYY-MM-DD'로 변경
    """
    try:
        # 날짜 컬럼 이름 확인
        if 'Day of #1-1. Recency' in df.columns:
            # 공백 제거 및 한글 날짜를 ISO 형식(YYYY-MM-DD)으로 변환
            df['Day of #1-1. Recency'] = (
                df['Day of #1-1. Recency']
                .astype(str)  # 데이터가 문자열 형식임을 보장
                .str.strip()  # 공백 제거
            )
            df['Day of #1-1. Recency'] = pd.to_datetime(
                df['Day of #1-1. Recency'], 
                format='%Y년 %m월 %d일')
            ).dt.strftime('%Y-%m-%d') 
            print(f"Formatted 'Day of #1-1. Recency' column to 'YYYY-MM-DD'.")
    except Exception as e:
        print(f"Error formatting date columns: {e}")
    return df

def fetch_tableau_data():
    """
    Tableau에서 데이터를 가져와 DataFrame으로 처리하고 CSV 데이터를 반환합니다.
    """
    # Tableau config
    config = {
        'tableau_prod': {
            'server': settings['TABLEAU_URL'],
            'api_version': '3.24',
            'personal_access_token_name': settings['TABLEAU_PERSONAL_ACCESS_TOKEN_NAME'],
            'personal_access_token_secret': settings['TABLEAU_PERSONAL_ACCESS_TOKEN_SECRET'],
            'site_name': settings['TABLEAU_SITE_ID'],
            'site_url': settings['TABLEAU_SITE_ID'],
        }
    }

    # Tableau 서버 연결
    conn = TableauServerConnection(config_json=config, env='tableau_prod')
    conn.sign_in()
    print("Connected to Tableau Server!")

    # 데이터 가져오기
    view_id = "d0c284ea-ce86-4b9d-8864-b0bf0105118f"
    response = conn.query_view_data(view_id=view_id)

    # CSV 데이터를 DataFrame으로 변환
    csv_data = BytesIO(response.content)
    df = pd.read_csv(csv_data)

    # created_at 컬럼 추가
    today_date = datetime.now().strftime('%Y-%m-%d')
    df['created_at'] = today_date

    # 날짜 컬럼 형식 변경
    df = format_date_columns(df)

    # DataFrame을 CSV로 변환
    csv_with_created_at = df.to_csv(index=False)

    # 데이터 확인 로그
    print(f"DataFrame shape: {df.shape}")
    print(f"DataFrame preview: \n{df.head()}")
    conn.sign_out()

    return csv_with_created_at

def main(request, context):
    """
    Cloud Function의 엔트리포인트 함수.
    """
    try:
        # Tableau 데이터 가져오기
        csv_data = fetch_tableau_data()

        # GCS에 CSV 저장
        save_csv_to_gcs(csv_data)

        return f"Data fetched and saved to {bucket_name}/{blob_name}.", 200
    except Exception as e:
        print(f"Error: {str(e)}")
        return f"Error: {str(e)}", 500

이제 csv가 자동으로 저장되었으니 빅쿼리로 퍼다 날라야 되니 그 추가로 함수를 만들어 준다

이 때 이 함수는 위에서 언급한대로선택한 버킷에서 파일 완료/생성 시 되어야 된다

import os
import logging
from datetime import datetime
import pandas as pd
from io import StringIO 
from google.cloud import storage
from google.cloud import bigquery
from google.cloud.exceptions import NotFound

# 로깅 설정
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

bucket_name = "bucket_rfm_history"
dataset_id = "bucket_data"
table_id = "rfm_history"

# 컬럼 매핑 딕셔너리
COLUMN_MAPPING = {
    "RFM score": "rfm_score",
    "#1-2. Frequency": "frequency",
    "#1-3. Monetary": "monetary",
    "#4. RFM Seg": "rfm_seg_nm",
    "Cust Id": "cust_id",
    "Day of #1-1. Recency": "recency",
    "created_at": "created_at",
}

# 컬럼 타입 지정
COLUMN_TYPES = {
    "rfm_score": "int64",
    "frequency": "int64",
    "monetary": "int64",
    "recency": "datetime64[ns]",
    "created_at": "datetime64[ns]",
}


def sanitize_and_map_columns(df):
    """
    컬럼 이름을 요청된 이름으로 매핑하고, 소문자로 변환합니다.
    """
    new_columns = []
    for col in df.columns:
        if col in COLUMN_MAPPING:
            # COLUMN_MAPPING에 정의된 컬럼 이름 우선 사용
            new_columns.append(COLUMN_MAPPING[col])
        else:
            # 허용되지 않는 문자 제거 및 알파벳, 숫자, 밑줄(_)로만 구성
            sanitized_col = ''.join(char if char.isalnum() or char == '_' else '_' for char in col)
            sanitized_col = sanitized_col.lower().strip('_')  # 소문자 변환 및 앞뒤 밑줄 제거

            # 첫 글자가 '_'로 시작하지 않도록 수정
            if sanitized_col.startswith('_'):
                sanitized_col = sanitized_col[1:]

            new_columns.append(sanitized_col)
    df.columns = new_columns
    return df


def convert_column_types(df):
    """
    컬럼 타입을 지정된 형식으로 변환합니다.
    """
    for col, dtype in COLUMN_TYPES.items():
        if col in df.columns:
            try:
                if "datetime" in dtype:
                    df[col] = pd.to_datetime(df[col], errors="coerce")
                else:
                    df[col] = df[col].astype(dtype)
                logger.info(f"Converted column '{col}' to type '{dtype}'.")
            except Exception as e:
                logger.error(f"Error converting column '{col}' to type '{dtype}': {e}")
    return df


def get_bigquery_table_schema(bigquery_client, dataset_id, table_id):
    """
    기존 BigQuery 테이블의 스키마를 가져옵니다.
    """
    try:
        table_ref = bigquery_client.dataset(dataset_id).table(table_id)
        table = bigquery_client.get_table(table_ref)
        logger.info(f"Existing table schema: {table.schema}")
        return table.schema
    except NotFound:
        logger.info(f"Table {table_id} not found. A new table will be created.")
        return None


def load_csv_to_bigquery(bucket_name, file_name, dataset_id, table_id):
    """
    Cloud Storage에 업로드된 CSV 파일을 BigQuery 테이블에 로드하는 함수.
    """
    if not file_name.endswith('.csv'):
        logger.info(f"Skipping non-CSV file: {file_name}")
        return f"File {file_name} is not a CSV. Skipped."

    logger.info(f"Processing file: {file_name} from bucket: {bucket_name}")

    # GCS에서 파일 다운로드
    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(file_name)
    csv_data = blob.download_as_string().decode('utf-8')

    # CSV 데이터를 DataFrame으로 로드
    df = pd.read_csv(StringIO(csv_data))

    # 컬럼 이름 정리 및 매핑
    df = sanitize_and_map_columns(df)

    # 컬럼 타입 변환
    df = convert_column_types(df)

    logger.info(f"Sanitized and mapped columns: {df.columns.tolist()}")
    logger.info(f"Loaded DataFrame with shape: {df.shape}")
    logger.info(f"DataFrame preview: \n{df.head()}")

    # BigQuery 클라이언트 초기화
    bigquery_client = bigquery.Client()

    # 테이블 스키마 확인 또는 생성
    existing_schema = get_bigquery_table_schema(bigquery_client, dataset_id, table_id)
    if not existing_schema:
        logger.info(f"Creating new table {table_id}.")
        schema = [
                    bigquery.SchemaField(
                        name,
                        bigquery.enums.SqlTypeNames.INTEGER if dtype == "int64" 
                        else bigquery.enums.SqlTypeNames.DATE if "datetime" in dtype 
                        else bigquery.enums.SqlTypeNames.STRING)  # 기본값: 문자열
                    for name, dtype in COLUMN_TYPES.items()
        ]       
        
        # DataFrame 컬럼 중 `COLUMN_TYPES`에 없는 컬럼도 문자열로 추가
        for col in df.columns:
            if col not in COLUMN_TYPES:
                schema.append(bigquery.SchemaField(col, bigquery.enums.SqlTypeNames.STRING))

        table_ref = bigquery_client.dataset(dataset_id).table(table_id)
        table = bigquery.Table(table_ref, schema=schema)
        bigquery_client.create_table(table)
        logger.info(f"Table {table_id} created.")
    else:
        # 기존 스키마와 맞춰 DataFrame 조정
        schema_field_names = [field.name for field in existing_schema]
        df = df[[col for col in df.columns if col in schema_field_names]]
        logger.info(f"Adjusted DataFrame to match existing schema: {df.columns.tolist()}")

    # BigQuery로 데이터 삽입
    table_ref = bigquery_client.dataset(dataset_id).table(table_id)
    job = bigquery_client.load_table_from_dataframe(df, table_ref)
    job.result()

    logger.info(f"Loaded {df.shape[0]} rows into {dataset_id}:{table_id}.")
    return f"Loaded {df.shape[0]} rows into {dataset_id}:{table_id}."


def get_latest_file_from_bucket(bucket_name):
    """
    Cloud Storage에서 가장 최근 파일 이름 반환.
    """
    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blobs = list(bucket.list_blobs())
    if not blobs:
        raise ValueError("No files found in bucket.")
    blobs.sort(key=lambda blob: blob.time_created, reverse=True)
    return blobs[0].name


def main(event, context):
    """
    Cloud Function 엔트리포인트.
    """
    try:
        file_name = get_latest_file_from_bucket(bucket_name)
        result = load_csv_to_bigquery(bucket_name, file_name, dataset_id, table_id)
        logger.info(result)
        return result
    except Exception as e:
        logger.error(f"Error: {str(e)}")
        return f"Error: {str(e)}"

이 함수가 동작하면 이제 빅쿼리에 아래와 같이 적재가 된다.

빅쿼리에 태블로 view 데이터 저장하기

이제 여기서 이걸 브레이즈(Braze) 에 API 를 쓸 수 있게 되면 더 편리해질 것 같다.

다음 편에서는 GCP 에서 Cloud Functions 를 활용해서 빅쿼리를 쿼리하는 API 를 만드는 방법을 소개해볼 예정이다.

https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api.htm

Tableau Server REST API

With the Tableau Server REST API you can manage and change Tableau Server, Tableau Cloud site, and Prep Conductor resources programmatically, using HTTP

help.tableau.com

GoogleAnalytics4 세그먼트 제대로 활용하기

알랭드보통 사람 — Mon, 19 Aug 2024 15:50:40 +0900

GA 세그먼트란?

분석 데이터의 하위 집합입니다.

사용자, 세션, 이벤트 데이터를 분리해서 세그먼트를 정의하면 분석하고자 하는 대상을 쉽게 정의할 수 있게 만드는 기능입니다.

세그먼트를 정의하게 되면 특정 유저의 그룹 vs 나머지 유저의 특징을 비교 분석해 볼 수 있습니다.

활용 방법 및 예시

GA4에서 세그먼트 기능을 통해 웬만한 유저들의 특징을 잡아낼 수 있습니다.

그런데 GA4가 어떻게 유저들의 행동 데이터를 수집하고 활용하는지 제대로 알지 못하면 활용하기 힘들겠죠?

이번 글에서는 큰 틀에서 GA4가 어떤 원리로 조건이 설정되는지 알아보려고 합니다.

세그먼트 유형 선택하기

세그먼트 생성화면을 들여다보면 꽤 많은 조건들을 설정할 수 있는 기능들이 많습니다.

일단 크게 3가지 유형의 세그먼트가 있습니다. (아래 유형에 대한 이해를 잘하셔야 합니다.)

세그먼트 유형 선택은 세그먼트를 조건에 해당하는 결과와 관련이 있는 거라고 생각하시면 이해하시기 쉬울 겁니다.

특히! 각 유형별로 소스 / 매체 선택할 때 주의할 점을 꼭! 숙지하시길 바랍니다!

GA4 세그먼트 생성

사용자 세그먼트 : 특정 기준을 충족하는 사용자의 모든 이벤트를 포함하게 만듦
- "방문자"와 관련된 분석을 한다면 사용자 세그먼트를 활용
- 아래 세그먼트 중에 가장 큰 범위
- 룩백 윈도우 (일반적으로 90일) 내에 사용자의 전체 구매 경로를 고려함
- 트래픽 소스를 정의할 때는 First User(첫 사용자) ~ 로 시작하는 접두사만 선택됩니다.

사용자 세그먼트내 트래픽 소스 정의할 때 범위가 사용자 범위로 되어 있는 첫 사용자 소스/메체 선택

세션 세그먼트 : 모든 이벤트가 포함되지만 기준과 일치하는 세션만 포함
- 방문자보다 "방문"에 초점을 맞추는 세그먼트
- 예를 들어 전환이 발생한 특정 세션과 그 순간 유저를 사이트로 유도한 트래픽 소스를 살펴볼 때!
- 트래픽 소스를 정의할 때 접두사에 Session 이 되어야 함

세션 세그먼트내 트래픽 소스 정의할 때 범위가 세션 범위로 되어 있는 세션 소스/메체 선택

이벤트 세그먼트 : 기준을 충족하는 특정 이벤트만 포함
- 사용자, 세션 기반 세그먼트에 비해 더 구체적인 분석이 가능합니다.
- 트래픽 소스를 정의할 때 접두사가 없어야 함

이벤트 세그먼트내 트래픽 소스 정의할 때 측정기준이 기여로 되어 있는 소스/메체 선택

이렇게 정의는 그럭저럭 이해는 할 수 있지만 역시 예시를 통해 어떻게 데이터가 선택되는지 알아보겠습니다.

특정 유저가 2개의 세션 안에서 몇 가지 이벤트를 발생시켰다고 가정해 보겠습니다.

예시) 1명의 유저가 생성한 2개의 세션

1. 사용자 세그먼트 예시

사용자 세그먼트 기준으로 구매한 유저를 세그먼트를 만들면 어떻게 데이터가 선택될까요?

총 7개의 이벤트가 모두 선택됩니다. 사용자 기준이니까 조회한 날짜에 있는 이벤트가 모두 포함되기 때문입니다.

사용자 세그먼트 예시

2. 세션 세그먼트 예시

최소 한 개의 구매 이벤트가 발생한 모든 세션의 데이터기 때문에 이 기준으로 충족되는 데이터는 purchase(구매) 이벤트가 발생한 session - 2 만 선택됩니다( session - 1 에는 구매 이벤트가 없음)

세션 세그먼트 예시

3. 이벤트 세그먼트 예시

이벤트 기준이면 기준에 맞는 이벤트만 선택한다는 말이기 때문에 session - 2에서 발생한 purchase 이벤트만!! 선택됩니다. 다른 이벤트는 선택 안됩니다!

이벤트 세그먼트 예시

조건 범위 설정하기

여기서는 어떤 조건의 유저를 선택할지 셋팅하는 옵션을 선택할 수 있습니다.

여기서 AND, OR 조건을 선택할 수 있는데 회원가입과 구매 이벤트를 발생시킨 유저 선택해 보겠습니다.

그런데 하단에 보면 포함할 조건 그룹 추가라는 버튼이 있습니다.

동일한 방식으로 회원가입과 구매를 한 조건을 설정하면 이렇게 할 수 있죠

즉 하나의 조건 그룹에 회원가입 이벤트와 구매 이벤트를 선택한 것이고 나머지 하나는 두 개의 조건 그룹에 회원가입 이벤트와 구매 이벤트가 각각 설정을 했습니다.

첫 번째 방식과 차이점은 뭘까요? 동일한 결과가 나올까요? 결과는 동일합니다.

???

이게 무슨 말이냐면 그룹 간 영역에서 오른쪽 상단에 보면 사람모양의 드롭다운 버튼이 있습니다.

이걸 클릭하면 조건 범위를 지정할 수 있습니다.

세그먼트 설정할 때랑 동일한 방식이죠? 사용자, 세션, 이벤트 단위로 조건설정이 가능합니다.

모든 세션
- 이 조건일 때 동일한 조건 그룹에 여러 가지 조건이 있으면 조건 A가 session - 1에서 발생하고 조건 B가 session - 2에서 발생했다면 유저는 세그먼트에 포함됩니다.
- 이 조건일 때는 유저의 Life Time 동안 조건이 충족됩니다
동일 세션 내
- (세그먼트 생성 시 사용자 세그먼트를 선택했어도) 조건 A랑 조건 B가 동일한 세션(session - 1 or session - 2)내에서 발생하는 조건
동일 이벤트 내
- (세그먼트 생성시 사용자 세그먼트를 선택했어도)조건 그룹이 단일 이벤트에서 발생

세션 및 이벤트 세그먼트에는 조건 지정 범위에 대한 옵션이 더 적습니다. 아래 표는 사용할 수 있는 세그먼트 유형별 조건 범위 간 조합입니다.

	사용자 세그먼트	세션 세그먼트	이벤트 세그먼트
모든 세션	✅	❌	❌
동일 세션 내	✅	✅	❌
동일 이벤트 내	✅	✅	✅

다시 예시를 들어볼게요

GA4에서 첫 구매 유저를 따로 이벤트를 개발하지 않으면 특정하기 힘든데 회원가입 후 첫 구매 유저를 세그먼트로 한 번 만들어 보겠습니다.

해당 유저들을 특정하기 위한 필요한 이벤트는 first_visit(첫 방문)과 purchase 이벤트겠죠?

첫 구매 유저를 특정한다고 해도 이를 어떻게 정의하느냐에 따라 결과는 달라집니다! (주의!!)

유저의 행동은 정말 엄청나게 많은 경우의 수로 발생을 하죠.

A유저 : 구매 의사 결정이 빠른 A유저는 동일한 세션 시간 내에서 구매

B유저 : 구매 의사 결정이 느린 B유저는 어제 상품을 처음 둘러보고 내일 구매

이 예시처럼 첫 구매를 동일한 세션 시간내 첫 구매를 한 유저를 특정할 것인지, 세션에 상관없이 첫 구매 유저를 식별한 것인지 정의하기 나름입니다.

첫 구매 유저 세그먼트를 만든다면 어떤 조건을 설정해야 될까요?

사용자 세그먼트를 기준으로 세그먼트를 설정하면 유저의 조건에 해당하지 않는 방문데이터도 포함되게 됩니다.

그러니까 첫 방문 이후 첫 세션에 구매를 하지 않아도 구매를 특정시킨 뒤에 제외 조건을 구매 조건을 2번 이상으로 설정하여 첫 구매한 유저를 식별할 수 있습니다.

그런데 first_visit, 첫 구매 사용자의 방문 데이터만 확인하고자 한다면 사용자 세그먼트가 아닌 세션 세그먼트를 기준으로 동일 세션 내의 조건 범위를 선택하여 세그먼트를 생성해야 합니다.

첫 구매 유저를 모든 세션 범위 조건으로 하여 세그먼트를 생성하고 재구매자(purchase 이벤트가 2번 이상)와 겹치는 부분이 없는지 세그먼트 중복 기능을 활용해 벤다이어그램으로 확인해 보겠습니다.

중복 없이 잘 나뉘었습니다. 이런 식으로 내가 가진 유저의 특징을 세그먼트로 만들어서 비교해 보는 과정이 굉장히 중요한 것 같습니다.

이 개념을 토대로 한 번 만들어 보시면 좋을 것 같습니다.

결론

GA의 세그먼트는 생각보다 할 수 있는 게 많긴 합니다.

하지만 제대로 활용하기 위해서는 위에 설명한 개념들이 잘 정리가 되어 있어야 됩니다.

이번 글을 쓰면서 느낀 건 솔직히 GA4는 사실 Amplitude를 사용해 봤다면 이런게 다 있나 싶을 정도로 불편하고... 뭔가 찜찜한 느낌을 지울 수 없었습니다.

이번 글에서 첫 구매 유저 세그먼트를 예시로 들었는데 GA4에서 First time purchases라는 측정항목이 존재하긴 하지만

이를 세그먼트로 활용은 못합니다... 약간 독립적인 측정항목 같은 느낌입니다.

GA4내 First time purchasers(처음 구매자 수)라는 측정항목의 정의를 진짜 유저의 히스토리컬 데이터를 기반으로 첫 구매 이벤트를 측정한다고 합니다. 이걸 그런데.. 세그먼트로 못쓴다니..

Amplitude에서는 사실 아주 간단하게 첫 구매 유저를 특정할 수 있는 Historical Count 기능이 있어서.. 아쉬웠습니다.

(물론 제약 조건은 있습니다. 날짜 범위가 시작되기 전 최대 1년까지 기간만 포함됩니다. 그래도 이건 혁명적인 기능!)

본질적으로 GA의 목적은 유저 획득에 초점을 맞춰져 있다면 Amplitude는 Product Analytics 툴로 사용자 행동 분석에 초점이 맞춰져 있긴 합니다. 그래서 목적에 맞지 않아서 해당 기능 개발을 하지 않은 건가 싶기도 합니다.

당장 앰플리튜드를 도입하지 않을 거라면 속 편하게 GA4에서 First Purchase 이벤트 개발을 요청하거나 혹은 일단 소개드린 방식대로 우선 트렌드만 확인하는 용도로 세그먼트를 생성해서 데이터를 분석하시는 걸 권장드립니다.

GA4에서 세션 지표는 이해하고 사용하셔야 합니다.

알랭드보통 사람 — Thu, 8 Aug 2024 17:08:59 +0900

Google Analytics를 사용해 보셨다면 ‘세션’이라는 용어에 익숙하실 것입니다. Universal Analytics(GA3)에서는 세션 단위로 데이터를 수집하여 지표를 측정했지만, GA4에서는 데이터 수집 방식이 달라져 주의가 필요합니다. GA4의 세션 관련 지표는 혼란을 일으킬 수 있습니다.

이번 글에서는 세션의 개념을 자세히 살펴보고, GA4에서의 세션이 어떻게 다른지 알아보겠습니다.

세션이란?

세션 관련해서 구글 가이드 문서에 따르면

- 세션은 사용자가 웹사이트 또는 앱과 상호작용하는 기간입니다.
- 세션은 사용자가 앱을 포그라운드에서 열거나 페이지나 화면을 보고 현재 활성화된 세션이 없는 경우 시작됩니다.
- 세션 수 : 고유 세션 ID 수를 추정하여 사이트나 앱에서 발생하는 세션 수를 계산합니다.

예를들어 유저가 브라우저 탭에서 페이지를 열고 이메일을 확인하거나 다른 일을 하다가 2시간 뒤에 다시 돌아와서 브라우징을 할 수 있겠죠? GA4에서는 이를 페이지 뷰가 있는 세션으로 보고 2시간 뒤에 사용자 참여로 간주하고 새로운 세션으로 기록합니다.

첫 번째 세션:
- 사용자가 오전 9시에 웹사이트의 특정 페이지를 엽니다.
- 페이지 조회(page view) 이벤트가 발생하여 세션이 시작됩니다.
두 번째 세션:
1. 사용자가 같은 페이지를 오후 2시에 다시 돌아와 사이트를 탐색합니다

이때 새로운 세션이 시작되지만 페이지 조회 이벤트는 기록되지 않습니다.→ 두 번째 세션이 사용자 참여로만 기록됩니다

빅쿼리로 실제 어떤 케이스인지 특정 유저의 로그를 한 번 확인 해보겟습니다.

빅쿼리 조회 결과 - 페이지뷰가 없는 세션

이렇게 페이지뷰 이벤트가 없는 두 번째 세션이 생기며, 이는 참여율(Engagement Rate) 지표로 나타납니다.

참여율 = 참여 세션 수 / 총 세션 수

참여 세션의 정의
- 10초 이상 머문 경우 (GA4 설정 : 10~60초로 조정 가능)
- 페이지뷰가 2회 이상 발생한 경우
- 10초이내로 머물러도 전환이벤트를 발생시킨 경우

GA4 인터페이스

이런 유저가 많아지면 세션 기반의 지표(예: 세션당 페이지뷰, 세션당 평균 참여시간)가 낮아집니다.

세션당 페이지뷰 수 계산 예시:

페이지뷰 수 / 세션 수 = 10 / 1 = 10

위와 같은 유저의 행동이 늘어나면:

페이지뷰 수 / 세션 수 = 10 / 2 = 5

페이지뷰 이벤트가 포함되지 않은 세션이 발생하니 지표가 감소하게 됩니다.(분모가 커지므로)

따라서 GA3에서 사용하던 세션 기반의 지표는 주의해서 사용해야 하며, 이벤트나 참여 관련 지표(참여 세션)를 보는 것이 좋습니다.

(GA4와 GA3의 데이터 수집 방식도 다릅니다)

자.. 그리고 또 있습니다.

세션 데이터의 현실.. 빅쿼리를 열어보면 .. 더 조심해야겠구나 라는 생각이 들껍니다.

일단 절대 세션수 ≠ session_start 이벤트의 수 가 아닙니다.

왜그런지 직접 조회해보죠!

session_start 이벤트가 없는 세션이 있다?

아래 특정 유저의 세션을 특정해서 조회해봤습니다.

event_name 컬럼에 session_start 이벤트는 없고 다른 이벤트만 있죠?

session_start 이벤트가 없는 세션 ID

하나의 세션에 session_start 이벤트가 2개?

이런 상황은 빈번하지 않지만 발생할 수 있습니다. 하나의 세션에 두 개의 세션 이벤트가 발생했고, 심지어 사용자 아이디도 다릅니다.

GA4 인터페이스에서는 당연히 단일 세션으로 계산하지 않을 것 같지만 빅쿼리에서는 이런 케이스 때문에 user_pseudo_id와 ga_session_id를 조합해서 각 세션에 대한 고유 식별자를 만들어서 session 을 카운팅 해야됩니다.

concat(user_pseudo_id, (select value.int_value from unnest(event_params) where key = 'ga_session_id')) as session_id,

하나의 세션에 session_start가 두개

하나의 세션에 2개 이상의 소스?

GA3에서는 세션 윈도우(30분)가 지나면 완전히 새로운 세션이 시작되지만, GA4에서는 기존 세션이 계속 되기 때문에 이렇게 소스가 1개 이상 발생할 수 있습니다.

하나의 세션에 2개 이상의 소스

GA에서 세션은 어떻게 계산될까?

결론

구글 애널리틱스에서도 세션수를 집계할 때 추정값을 사용합니다.

실제로 빅쿼리에 count(distinct ga_sesssion_id) 를 집계하면 성능에 영향을 줍니다..

그런데 전 세계에서 이걸 조회하는데 이걸 진짜 집계를 ?? 불가능하죠

그래서 HyperLogLog ++ (가이드 링크)라는 알고리즘을 적용해서 추산한 값을 보여줍니다.

Google 애널리틱스의 고유 개수 근사값 | Google Analytics | Google for Developers

의견 보내기 Google 애널리틱스의 고유 개수 근사값 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 민하즈 카지, Google 애널리틱스 Developer Advocate – 2022년 10월

developers.google.com

실제로 성능을 눈으로 확인해보죠

ga_session_id를 고유하게 카운팅 해보는 쿼리로 비교를 해보겠습니다.

COUNT(DISTINCT ga_session_id)

  HLL_COUNT.EXTRACT(HLL_COUNT.INIT(ga_session_id, 14))

차이가 보이시나요? (참고로 데이터 하루치만 조회했고 쿼리 결과는 같습니다)

모든면에서 더 효율적인 처리를 하고 있음을 알 수 있습니다.

사실 GA4에서는 세션이라는 개념은 더 이상 의미가 없고 지금까지 위의 예시를 통해 확인할 수 있었습니다.

그럼에도 세션 지표를 무조건 써야된다면 참여 세션지표를 사용하는게 좋습니다.

이제 이걸 통해서 다음 글에서는 GA4의 꽃 세그먼트 분석에 대해서 알아보겠습니다.

(세그먼트 기능을 쓰려면 세션에 대한 이해가 꼭 필요하기 때문에 이번 글부터 시작하게 되었습니다.)

GA4 Query Explorer 에서 csv 파일로 바로 내려 받는 방법

알랭드보통 사람 — Fri, 2 Aug 2024 17:00:50 +0900

GA4 데이터를 따로 데이터 마트에 저장해서 활용하고 싶을 때

혹은 원하는 view의 테이블 형태를 조회하고 싶을 때

Query Explorer 를 한 번쯤을 들어가 보셨던 경험이 있으실 거예요 (링크)

https://ga-dev-tools.google/ga4/query-explorer/

ga-dev-tools.google

여기서 수집하려는 차원과 측정값을 선택해서 손쉽게 API를 호출해서 데이터를 확인해 볼 수 있습니다.

보통 Query Explorer에서 어떤 차원과 측정값을 가져올지 확인한다음 Google Analytics Data API를 사용해 데이터를 가져오는 코드를 작성해야 되는데 우리는 GPT로 인해 이런 수고를 덜 수 있게 되었습니다.

query explorer

위에 처럼 차원과 측정값을 선택하고 기호에 따라 정렬 혹은 필터도 가능합니다. 그런다음에 Make Request를 하면

api 호출하기

API 응답값을 바로 받아 볼 수 있습니다..

그런데... 데이터를 다운로드 받을 수 있는 버튼이 어디에도 없습니다...

하지만 우리는 이제 인공지능의 힘을 빌릴 수 있어서 Chat GPT를 소환합니다.

소환하기 전에 JSON 탭을 클릭하고 오른쪽에 복사 버튼을 눌러줍니다.

ga4 json 결과

sublime text(코드 편집기) 를 실행시켜 줍니다. visual studio code 도 상관없습니다.

없으시면 여기서 다운로드하여주세요 (링크)

Download - Sublime Text

Sublime Text 4 is the current version of Sublime Text. For bleeding-edge releases, see the dev builds. Sublime Text may be downloaded and evaluated for free, however a license must be purchased for continued use. There is currently no enforced time limit f

www.sublimetext.com

복사한 텍스트를 갖다가 붙여 넣어 주세요

sublime text 에 붙여 넣기

그다음에 . json 파일 확장자 형태로 저장해 줍니다

json 확장자로 파일 저장하기

GPT를 켜고 만든 json 파일을 던져 줍니다!

GPT에 csv 파일로 만들어달라고 프로프트 하기

다운을 받아보면 아까 Query Explorer에서 Table 형태로 확인한 그대로 파일을 생성된 걸 확인할 수 있습니다.

csv 파일

당장 일 배 치를 통해 데이터를 적재하지 않을 거라면 이방식으로 Query Explorer에서 바로 CSV 파일로 만들어서 확인할 수 있는 방법을 소개해봤습니다.

코호트 분석 - 제대로 측정하고 계신가요? (달력 기준 vs 24시간 기준)

알랭드보통 사람 — Thu, 1 Aug 2024 16:19:30 +0900

이 글을 읽고 계시다면 코호트 분석을 이미 하고 계실 건데 측정 기준에 대해서 의문이 생기신 분이 보실 것 같네요

구글에 '코호트 분석 SQL' 라고 검색하면 정말 많은 글들이 많습니다.

글에서 소개하는 쿼리 예시는 대부분 datediff함수를 활용해서 Date Granularity를 계산합니다.

이해하기 쉽게 예를 들어보겠습니다.

유저 1 : 23:30 에 회원가입 후 다음날 다시 들어왔습니다.

유저 2 : 13:30에 회원가입 후 다음날 다시 들어왔습니다.

day 단위로 계산을 하면 유저 1 은 우리 서비스를 30분 경험하고 다음날 재방문했다고 계산됩니다.

유저 2는 약 10시간 30분 서비스를 경험하고 재방문을 했다고 계산됩니다.

동일한 조건일까요? 그렇지 않죠?

만일 시간 단위로 계산을 하게 되면 특정 행동을 수행한 시간부터 다음 행동까지의 Time window를 24시간 뒤로 하면 이 유저는 다음날이 아닌 모레 재방문했다고 계산되겠죠?

DATEDIFF( [first_event_dt], [second_event], DAY )

DATEDIFF( [first_event_dt], [second_event], HOUR ) / 24 )

월단위로 계산할 때도 마찬가지입니다.

월별 일자수가 모두 다릅니다. 1월(31일), 2월(28일), 4월(30일)...

월 단위로 측정할 때도 30일로 모두 통일해줍니다.

DATEDIFF( [first_event_dt], [second_event], HOUR ) / 24  * 30)

이렇게 계산되면 유저별로 경과 시간은 모두 통일 되었습니다!!

실제로 Amplitude(앰플리튜드)의 코호트 분석 기능에는 이런 기능들이 존재합니다. 만약 안 쓰고 계시다면 직접 쿼리를 날려서...

여기 가이드를 보시면 앰플리튜드가 24시간 단위로 경과 시간을 측청 하는 방식을 설명해 두었습니다.

How time works in a retention analysis

This article helps you: Understand the different ways time can affect your Retention Analysis chart Choose the most appropriate time calculation for your analysis In a Retention Analysis chart, there are two ways to define a day: a rolling 24-hour window o

amplitude.com

앰플리튜드 화면 캡쳐

24시간 윈도우 기준, 캘린더 기준으로 경과 시간(t)을 측정하는 옵션이 있죠?

얼마나 차이를 보였는지 가상의 데이터로 확인을 해보았습니다.

(참고로 더미 데이터는 kaggle 이나 Mockaroo 에서 생성하실 수 있습니다)

참고로 해당 데이터 계산 기준은 월별 첫 구매 기준 재구매율입니다.

t = 1 지점부터 차이를 보이기 시작하는데 t = 0 이 100%라서 차이가 잘 안 보입니다. 로그 스케일을 통해 다시 확인해 보면

확실히 달력 기준의 리텐션율이 조금 더 높아 보이네요

얼마나 차이 나는지 두 기준의 리텐션율을 나눠 보겠습니다 최대 1.27배까지 납니다. (아래 차트에서는 0은 무시합니다. t = 0 은 100%이기 때문에)

t = 1 : 1.15배

t = 22 : 1.27배

데이터에 따라서 차이가 달라지겠지만

코호트의 기준이 만일 회원가입일 기준의 재구매율이거나 회원가입일 기준 재방문율을 측정한다면 더 많은 차이를 보일 수 있을 걸로 예상됩니다.

제가 사용한 쿼리는 아래와 같습니다.

WITH tb_pay_first AS (
        SELECT country
                ,user_id
                ,min(pay_datetime_id) first_pay_datetime_id
        FROM order
        GROUP BY 1,2

)

, tb_base_ AS (SELECT  st0.*
                    , FLOOR(TIMESTAMPDIFF(HOUR, st1.first_pay_datetime_id, st0.pay_datetime_id) / 24) AS days_since_first_pay
                    , FLOOR(TIMESTAMPDIFF(HOUR, st1.first_pay_datetime_id, st0.pay_datetime_id) / (24 * 30)) AS months_since_first_pay_period_24h
                    , (YEAR(pay_datetime_id) - YEAR(first_pay_datetime_id)) * 12 + (MONTH(pay_datetime_id) - MONTH(first_pay_datetime_id)) AS months_since_first_pay_period_day
                    , st1.first_pay_datetime_id
            FROM order st0
            LEFT JOIN tb_pay_first st1
                ON st0.user_id = st1.user_id
                AND st0.country = st1.country
            WHERE 1 = 1

)

, tb_base_24h AS (
                SELECT time_id_
                        , country
                        , since_time_period_24h
                        , CASE 
                            WHEN 'acc' = 'normal' THEN SUM(SUM(IF(since_time_period_24h = max_since_time_period_24h, repurchase_user_cnt, 0))) OVER 
                                (PARTITION BY time_id_, country ORDER BY since_time_period_24h DESC RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
                            ELSE SUM(repurchase_user_cnt)
                            END AS repurchase_user_cnt
                        , count(1) pay_user_cnt
                        , sum(sales) AS sales

                FROM   (SELECT *
                                , CASE WHEN since_time_period_24h = 0 AND pay_cnt > 1 THEN 1
                                        WHEN since_time_period_24h = 0 AND pay_cnt <= 1 THEN 0
                                        ELSE 1 
                                    END AS repurchase_user_cnt
                                , MAX(since_time_period_24h) OVER (PARTITION BY country, user_id) as max_since_time_period_24h
                        FROM
                                (SELECT tmp0.time_id_
                                        , tmp0.country
                                        , tmp0.since_time_period_24h 
                                        , tmp0.user_id
                                        , SUM(tmp0.pay_cnt) AS pay_cnt
                                        , SUM(tmp0.sales) AS sales
                                FROM 
                                        (SELECT DATE_FORMAT(first_pay_datetime_id ,'%Y-%m-01') time_id_
                                                , country
                                                -- , months_since_first_pay_period_day AS since_time_period_day
                                                , months_since_first_pay_period_24h AS since_time_period_24h
                                                , user_id
                                                , COUNT(distinct order_id) AS pay_cnt
                                                , SUM(sales) as sales
                                        FROM tb_base_
                                        -- WHERE DATE_FORMAT(first_pay_datetime_id ,'%Y-%m-01') >= '2023-01-01'
                                        GROUP BY 1,2,3,4) tmp0
                                GROUP BY tmp0.time_id_
                                        , tmp0.country
                                        , tmp0.since_time_period_24h 
                                        , tmp0.user_id
                                ) tmp
                                    ) tmp1
                GROUP BY time_id_ 
                        , country
                        , since_time_period_24h
)

, tb_base_day AS (
                SELECT time_id_
                        , country
                        , since_time_period_day
                        , CASE 
                            WHEN 'acc' = 'normal'  THEN SUM(SUM(IF(since_time_period_day = max_since_time_period_day, repurchase_user_cnt, 0))) OVER 
                                (PARTITION BY time_id_, country ORDER BY since_time_period_day DESC RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
                            ELSE SUM(repurchase_user_cnt)
                            END AS repurchase_user_cnt
                        , count(1) pay_user_cnt
                        , sum(sales) AS sales
                FROM   (SELECT *
                                , CASE WHEN since_time_period_day = 0 AND pay_cnt > 1 THEN 1
                                        WHEN since_time_period_day = 0 AND pay_cnt <= 1 THEN 0
                                        ELSE 1 
                                    END AS repurchase_user_cnt
                                , MAX(since_time_period_day) OVER (PARTITION BY country, user_id) as max_since_time_period_day
                        FROM
                                (SELECT tmp0.time_id_
                                        , tmp0.country
                                        , tmp0.since_time_period_day 
                                        , tmp0.user_id
                                        , SUM(tmp0.pay_cnt) AS pay_cnt
                                        , SUM(tmp0.sales) AS sales
                                FROM 
                                        (SELECT DATE_FORMAT(first_pay_datetime_id ,'%Y-%m-01') time_id_
                                                , country
                                                , months_since_first_pay_period_day AS since_time_period_day
                                                -- , months_since_first_pay_period_24h AS since_time_period_24h
                                                , user_id
                                                , COUNT(distinct order_id) AS pay_cnt
                                                , SUM(sales) as sales
                                        FROM tb_base_
                                        GROUP BY 1,2,3,4) tmp0
                                GROUP BY tmp0.time_id_
                                        , tmp0.country
                                        , tmp0.since_time_period_day 
                                        , tmp0.user_id
                                ) tmp
                                    ) tmp1
                GROUP BY time_id_ 
                        , country
                        , since_time_period_day
)


, cohort_base_24h AS 
                (SELECT time_id_
                    , country 
                    , since_time_period_24h
                    , repurchase_user_cnt
                    , pay_user_cnt
                    , sales
                    , SUM(sales) OVER w AS acc_sales
                    , FIRST_VALUE(pay_user_cnt) OVER w AS cohort_user_cnt
                    , COUNT(1) OVER (PARTITION BY country) AS cohort_cnt
                FROM tb_base_24h
                WINDOW w AS (PARTITION BY time_id_, country ORDER BY since_time_period_24h RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
                )
)

, cohort_base_day AS 
                (SELECT time_id_
                    , country 
                    , since_time_period_day
                    , repurchase_user_cnt
                    , pay_user_cnt
                    , sales
                    , SUM(sales) OVER w AS acc_sales
                    , FIRST_VALUE(pay_user_cnt) OVER w AS cohort_user_cnt
                    , COUNT(1) OVER (PARTITION BY country) AS cohort_cnt
                FROM tb_base_day
                WINDOW w AS (PARTITION BY time_id_, country ORDER BY since_time_period_day RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
                )
)


SELECT *
    , (pay_user_cnt * 100) / cohort_user_cnt AS retention_rate
FROM
            (SELECT 1 AS time_id
                    , country
                    , since_time_period_24h
                    , SUM(repurchase_user_cnt) AS repurchase_user_cnt
                    , SUM(pay_user_cnt) AS pay_user_cnt
                    , FIRST_VALUE(sum(cohort_user_cnt)) OVER(PARTITION BY country RANGE BETWEEN UNBOUNDED PRECEDING and CURRENT ROW) as cohort_user_cnt
            FROM cohort_base_24h
            GROUP BY 1
                    , country
                    , since_time_period_24h) tmp3

정리해 보면!

분석의 기준은 굉장히 중요합니다. 어떤 기준으로 분석하느냐에 따라서 의사결정 방향이 달라질 수 있겠죠?

코호트 분석은 시간을 계산해서 집계하는 분석인만큼 시간의 기준을 제대로 설정하는 게 중요합니다.

달력 단위의 코호트 측정이 조금 더 실제로 과대 평가되기 때문에 유저별로 통일된 24시간 기준으로 계산하여

코호트를 측정하는 것이 올바른 방법이라고 생각이 됩니다.

저도 실제로 분석해 보면서 분석 기준의 중요성을 다시 한번 깨달을 수 있었습니다.

혹시 지금 day 단위로 코호트 활용해 재구매율을 측정하고 계신다면 24시간 단위로 계산해 보시면 어떨까요?

Reference

https://medium.com/@paul.levchuk/how-to-build-user-cohort-properly-b70a74e5e1c8

MMP(AppsFlyer), GA4, Braze 데이터를 활용해 시각화할 때 반드시 고려해야할 사항(2)- 데이터 전처리하기

알랭드보통 사람 — Tue, 23 Jul 2024 14:32:01 +0900

지난 편에서는 각 솔루션별 데이터 수집 방법(바로가기)에 대해서 알아보았습니다.

MMP(AppsFlyer), GA4, Braze 데이터를 활용해 시각화할 때 반드시 고려해야할 사항(1)- Third Party 데이터

업무 시간을 데이터 수집과 데이터 전처리에 시간을 쓰는 마케터와 데이터 수집 자동화된 환경에서 성과 분석과 기획에 더 많은 시간을 쓰는 마케터 누가 더 많이 성장할까요?당연히 성과 분석

botongsaram.tistory.com

Third Party 데이터 수집 자동화
수집된 데이터 전처리하기
시각화하기

이번에는 수집된 데이터를 활용하여 어떻게 전처리 해야 되는지 알아보겠습니다.

각 데이터 셋들은 분석하려는 차원(dimension)을 기준으로 집계(group by)를 통해서 동일한 형태로 전처리한 후 조인 연산을 통해 데이터를 통합하는 과정이라고 생각하시면 됩니다.

마케팅 성과를 분석하기 위해서 필요한 데이터 다음과 같습니다.

(필요에 따라서 Dimension 의 개수는 추가될 수 있습니다. ex)device_category, country, 등등)

Dimension : 날짜(일별), 유입소스(GA4 = utm_source, Appsflyer = Media_source), 캠페인

Metric : 구매수, 매출, 인스톨 수

구매 데이터(MMP, GA4) 통합하기

GA4가 웹, 앱 모두 트래킹을 할 수 있지만 WEB은 GA4, APP은 MMP로 성과를 합쳐서 보실 겁니다.

GA4, Firebase는 앱과 웹 내 고객 행동 분석에 주로 쓰이는 툴이고 MMP 는 광고 성과를 측정하는 툴이니깐요

그러면 이렇게 됩니다.

<GA4 데이터 집계> - WEB

Dimension : 날짜(일별), 세션 소스, 캠페인

Metric : 구매수, 매출

<MMP 데이터 집계> - APP

Dimension : 날짜(일별), Media_source, 캠페인

Metric : 구매수, 매출, 인스톨 수

집계된 두개의 테이블을 UNION 다시 한번 집계를 해줍니다.

이렇게 하면 집계된 웹앱 데이터 통합이 되었습니다. (MMP 데이터 전처리 과정은 생략)

Dimension : 날짜(일별), Media_source, 캠페인

Metric : 구매수, 매출, 인스톨 수

브레이즈 커런츠 데이터와 구매 데이터(MMP, GA4) 연결하기

브레이즈 커런츠(braze currents)데이터는 유저 인게이지먼트 데이터입니다.

여기에는 유저별로 어떻게 우리 서비스로 참여를 하고있는지를 기록한 데이터들이 기록되어 있으니 메시지 발송 수단별로 노출, 클릭 성과들이 들어있습니다. 하지만 우리는 성과(구매) 판단은 MMP, GA4로 해야 하므로 서로 다른 데이터들을 어떻게 통합해서 볼지를 알아보겠습니다.

커런츠 데이터는 아래와 같이 구성이 되어있습니다.

(차원 데이터 생성을 위한 함수는 태블로 함수입니다)

유니크한 ID 차원 만들기

위와 같은 데이터를 일자, 메세지 발송 타입, 캠페인 or 캔버스별 발송수, 노출수, 클릭수 데이터를 집계를 하기 위해서는 유니크한 ID를 나타내는 차원 데이터를 만들어 줘야 합니다.

동일한 유저라도 캠페인, 캔버스, 베리에이션 등 다양한 형태로 타겟이 될 수 있으므로, 아래와 같이 유니크한 차원 데이터를 만들기 위해 새로운 아이디를 생성합니다. (해당 아이디는 발송 타입별로 카운트하기 위해 활용됩니다.)

차원의 이름은 원하시는대로 명명하시면 되고 저는 user_id_dispatch_id 이렇게 명명하였습니다.

-- 태블로 계산식
IFNULL([User Id],'') + '-' +
IFNULL([Campaign Id],'') + '-' +
IFNULL([Message Variation Id],'') + '-' +
IFNULL([Canvas Id],'') + '-' +
IFNULL([Canvas Variation Id],'') + '-' +
IFNULL([Canvas Step Message Variation Id],'') + '-' +
IFNULL([Dispatch Id],'')

캠페인 차원 만들기

다음으로 캠페인 단위로 성과를 집계할 예정이기 때문에 캠페인 차원을 만들어줘야 합니다.

왜냐하면 브레이즈에는 캠페인과 캠버스로 나뉘는데 campaign_name 값이 존재하면 canvas_name 이 빈값이고 거꾸로 canvas_name 값이 존재하면 campaign_name이 빈값이기 때문입니다.

-- 태블로 계산식
IFNULL([Campaign Name],[Canvas Name])

발송 타입별 유니크한 ID 차원 만들기

{send_type}_click 이런 식으로 차원 이름을 명명하고 아래와 같은 태블로 계산식으로 차원을 만들어줍니다.

이렇게 되면 email_click, push_click, in_app_message_click 이벤트별로 ID(user_id_dispatch_id)를 생성됩니다.

-- 태블로 계산식
{ FIXED [user_id_dispatch_id],[Event Type] : COUNTD(IF CONTAINS([Event Type], 'inappmessage_click') THEN [user_id_dispatch_id] END)}

발송 타입 차원 만들기

최초에 S3에 적재된 currents 데이터(avro 파일)를 DW에 적재할 때 파일별 Event 구분을 위해 Event_Type 칼럼을 생성하였습니다. (이전 글을 참고해 주세요)

['users.messages.email.Open.avro',
'users.messages.email.Click.avro',
'users.messages.pushnotification.Send.avro',
'users.messages.inappmessage.Click.avro',
'users.messages.email.Delivery.avro',
'users.messages.pushnotification.Open.avro',
'users.messages.inappmessage.Impression.avro']

-- 태블로 계산식
IF CONTAINS([Event_Type], 'email') then 'email'
elseif CONTAINS([Event_Type], 'push') then 'push'
elseif CONTAINS([Event_Type], 'inappmessage') then 'iam' end

이제 집계를 위한 전처리는 완료되었습니다(세세한 전처리 과정은 생략됨)

이제 위에서 만들었던 차원을 가지고 집계를 합니다.

일자별, send_type, campaign/canvas, device_category 별 오픈, 클릭, 노출, delivery 데이터는 아래와 같이 집계되었습니다.

Braze Currents 전처리 / 집계한 테이블 예시

통합된 GA4 / MMP 데이터와 커런츠 데이터를 통합해야 되는 과정이 또 남았습니다.

어떻게 이 두 데이터를 엮어야 될까요?

조인키를 위에서 집계한 차원 데이터로 잡고 Full Outer Join으로 데이터를 조인합니다.

이유는 특정 날짜에 브레이즈 커런츠 데이터는 존재하는데 성과 데이터(GA4, MMP) 데이터가 존재하지 않는다면 매칭될 수 없으니 누락이 되어버립니다. 거꾸로 성과 데이터(GA4, MMP) 데이터가 존재하는데 브레이즈 커런츠 데이터가 존재하지 않을 경우 누락이 되어버리기 때문입니다.

광고 성과 데이터 전처리하는 예시를 통해 Full Outer JOIN 이 어떻게 데이터를 처리되는지 예시를 통해 잠깐 확인해 보겠습니다

2024년 1월 1일 twitter 채널의 e 캠페인에서 비용이 1000원 소진했습니다. 그런데 GA4, MMP 데이터에는 해당 광고 채널의 캠페인에서 전환이 아예 일어나질 않았습니다. 하지만 비용이 발생했기 때문에 이 데이터를 버릴 수는 없겠죠? 무조건 살려야 됩니다.

거꾸로 광고 데이터에서 비용은 발생하지 않았는데 Attribution Window로 인해 전환이 발생했습니다. 이것도 버릴 수 없겠죠?

이 두 데이터에서 LEFT JOIN 또는 RIGHT JOIN을 수행하게 되면 조인키에 대응하지 않은 데이터는 매칭이 안되어 누락이 되어 버립니다. 이를 방지하기 위해서 INNER, LEFT OUTER, RIGHT OUTER 조인 집합을 생성하는 FULL OUTER JOIN을 수행합니다.

결과를 보면 각 테이블의 모든 데이터들이 출력이 되는 걸 알 수 있습니다.

Full Outer Join 예시

본론으로 돌아와서!

Full Outer Join을 수행하기 전에 앞서 GA4, MMP 데이터를 합친 후 우리는 CRM 데이터만 필요하기 때문에 CRM 데이터만 필터를 합니다.

이제 Braze Current 데이터와 성과 데이터(GA4, MMP)를 날짜, 유입소스명, 캠페인명을 조인키로 두고 Full Outer Join 을 수행합니다.(분석하고자 하는 차원데이터가 추가로 더 있다면 추가로 필요한 차원도 조인키로 활용하시면 됩니다.)

이와 같은 방식으로 Paid 성과 데이터를 전처리 할 때도 위와 같은 방법으로 수행하면 됩니다.

데이터를 전처리 할 때 중요한 건 분석하고자 하는 결과물을 먼저 그려본 뒤에 결과를 도출하기 위해서 각 테이블을 어떻게 만들어 갈 것인지 생각하면서 만들어가면 됩니다. 실제로 전처리하다 보면 자잘하게 처리해야 되는 부분이 상당히 많습니다.

특히 데이터를 통합하기 위해서는 무엇보다 네이밍 컨벤션이 가장 중요한 점은 강조하지 않을 수 없습니다.

데이터 수집까지 잘했는데 캠페인 네이밍 컨벤션이 서로 다르다?.. 데이터 통합은 불가능합니다..

네이밍 컨벤션은 말 그대로 명명 규칙입니다.

위에서 언급한 대로 우리가 데이터 통합을 위해 차원 데이터를 조인키로 활용한다고 했었는데 캠페인 차원이 MMP, GA4, Braze or 광고 데이터가 모두 다르면 안 되겠죠? 아래와 같이 통일을 시켜야만 데이터를 연결할 수 있습니다.

MMP	GA4
Media Source(ex. meta)	UTM_SOURCE(ex. meta)
Campaign(ex. reach_asc_all)	Campaign(ex. reach_asc_all)

여기까지 마케팅 데이터 수집부터 전처리 과정까지 알아보았습니다.

다음 글에서는 이 데이터를 활용해서 시각화 하는 방법을 살펴보겠습니다.

MMP(AppsFlyer), GA4, Braze 데이터를 활용해 시각화할 때 반드시 고려해야할 사항(1)- Third Party 데이터 수집 자동화

알랭드보통 사람 — Tue, 9 Jul 2024 16:05:57 +0900

업무 시간을 데이터 수집과 데이터 전처리에 시간을 쓰는 마케터와 데이터 수집 자동화된 환경에서 성과 분석과 기획에 더 많은 시간을 쓰는 마케터 누가 더 많이 성장할까요?

당연히 성과 분석과 기획에 더 많은 시간을 쏟는 마케터가 장기적으로 성장성이 높을 겁니다.

이를 위해서 마케팅 데이터 파이프라인을 구축해서 분석화는 환경을 만들어야 합니다.

지금도 GA4, MMP(AppsFlyer), Braze를 사용하고 있는데 엑셀로 데이터 수집해서 가공하는 시간을 대부분을 사용하고 있다면.. 하루빨리 마케팅 데이터 수집 자동화하고 BI를 구축을 시도해 보세요.

관련 주제는 내용이 많아서 3개의 파트로 나눠서 글을 발행해보려 합니다.

Third Party 데이터 수집 자동화
수집된 데이터 전처리하기
시각화하기

이번 편에서는 MMP(AppsFlyer), GA4, Braze 데이터 수집을 자동화시키는 프로세스를 소개해볼까 합니다.

Third Party 데이터 수집 자동화

마케팅 데이터를 적재하고 시각화까지의 프로세스를 이해하기 쉽게 도식화하면 아래와 같습니다.

(아래 예시에서 Github Action은 스크립트를 자동화할 수 있는 역할을 하는 Github 이 제공하는 완전관리형 CI/CD 툴입니다)

마케팅 데이터 파이프라인 도식화 예시

브레이즈 Currents 데이터 수집하기

브레이즈 currents 란 유저의 engagement 이벤트의 실시간 데이터 스트림입니다.

BI 및 분석할 수 있는 데이터를 제공해 주는 기능이다라고 이해하시면 됩니다. 단점은 가격이.. 비싸요

데이터 수집은 클릭 몇 번으로 쉽게 수집할 수 있습니다

브레이즈 어드민에서 아래처럼 어떤 데이터를 보낼지 선택해서 어디에 저장할지 S3, Cloud Storage, Azure Blob Storage 중 선택해서 적재를 시작합니다.(가이드 링크)

브레이즈 커런츠 이벤트 선택 화면

브레이즈 커런츠 데이터를 Amazon S3에 보낸다면 아래 이미지와 같이 이벤트별로 폴더가 분리되어 적재가 됩니다.

(참고로 브레이즈 Currents는 At-least-once delivery 정책으로 1시간 단위로 데이터를 적재합니다.

그래서 중복된 이벤트가 가끔 스토리지 버킷에 저장될 수 있습니다. 그래서 DW에 적재할 때 고유 식별자 필드(id)를 사용해 이벤트 중복을 제거할 수 있습니다.)

Amazon s3 에 적재된 Braze Currents 데이터

이 많은 데이터중에서 필요한 이벤트 데이터들을 골라서 합쳐야 되는데 여기서 문제가 있습니다.

각 파일에는 이벤트를 구분하는 필드가 없습니다. 그래서 파일별로 어떤 이벤트의 파일인지 지정해줘야 합니다.

아래와 같이 Avro 파일 명을 확인하여 event_type 필드의 key 값을 추가 필요합니다

예를 들어 이메일 - open, click, delivery 이벤트 데이터, push - send, open 이벤트 데이터 그리고 인앱메세지의 - 노출, 클릭 데이터를 사내 DataWarehouse에 통합해서 적재한다고 할 때 event_type이라는 필드를 하나 만들어서 어떤 데이터인지 명시해 줘야 된다고 생각하시면 됩니다.

#	파일명	event_type 필드의 key 값(예시)
1	users.messages.email.Open.avro'	email_open
2	users.messages.email.Click.avro'	email_click
3	users.messages.email.Delivery.avro'	email_delivery
4	users.messages.pushnotification.Send.avro'	push_send
5	users.messages.pushnotification.Open.avro'	push_open
6	users.messages.inappmessage.Click.avro'	inappmessage_click
7	users.messages.inappmessage.Impression.avro'	inappmessage_Impression

추가로 조심해야 될 부분은 브레이즈 커런츠 데이터중에 시간을 나타내는 time이라는 필드가 있는데 UTC 기준이라 추후 전처리 할 때 원하는 시간대(KST)로 처리를 해줘야 합니다.

브레이즈 커런츠 데이터 예시

MMP(앱스플라이어) 데이터 수집하기

앱스플라이어 데이터는 사내에서 어떻게 집계할지 기준을 잡아주셔야 됩니다.

소개드리는 방식은 SKAN 중복이 어느 정도 발생할 수 있으나 현재까지는 소개드리는 방식이 최선입니다.

앱스플라이어 측에서 개선을 해주신다고 들었기 때문에 기대가 됩니다.

앱스플라이어 데이터를 집계하기 위해서는 여러 개의 리포트를 Export 해야 되는데요

아시겠지만 굉장히 번거로운 작업입니다.

데일리 리포트를 만들려면 OS별, UA, RT(리타겟팅) 별로 csv 파일을 12번 클릭해서 받아 정리해야 되지만 API를 활용하면 충분히 자동화할 수 있습니다.

필요한 API는 아래와 같습니다.

Raw data Pull API
- organic
  - install
  - in-app events
- non-organic
  - install
  - in-app events
Aggregate Pull API
- User Acquisition
- Retargeting
SKAN AGGREGATED PERFORMANCE REPORT API

Raw data Pull API 호출 횟수

SRN 매체인 메타 데이터의 집약형 리포트 호출 횟수

하루에 호출해야 되는 API가 굉장히 많죠? ㅜㅜ

참고로 앱스플라이어는 일별 API 호출 제한이 있어서 테스트하실 때 유의해야 합니다. (가이드 링크)

내가 지금 몇 번 호출했는지 확인하시려면 어드민에서 오른쪽 상단 > security center > audit log를 보시면 확인 가능합니다.

012

Appsflyer API 호출 횟수 확인하는 방법

그리고 또 하나 중요한 점은 서두에 언급했듯이 앱스플라이어 데이터를 어떻게 볼지 기준에 대해서 논의하시고 대행사와도 공유하는 걸 권장드립니다.

이게 무슨 말이냐면

앱스플라이어 rawdata를 보시다 보면 Media Source 값 중에 restricted라고 명시된 데이터를 보실 수 있습니다. 이건 SRN 매체들의 경우 개인정보보호 이슈로 rawdata에 포함하지 않기 때문입니다. 그래서 SRN 매체(메타, 핀터레스트, 트위터, 스냅챗 등)의 경우에는 집약형 데이터를 활용합니다.(가이드 문서 링크)

그런데 여기서 LTV라는 개념이 등장합니다. 평생가치라는 개념인데.. 앱스플라이어의 가이드 문서를 이용하면

LTV 데이터는 특정 날짜 범위에 앱을 전환/인스톨한 사용자의 일생동안 수행되는 이벤트입니다.

집계 데이터를 가져오기 위한 다양한 리포트 방법 비교표

위 표를 보시면 집약형 데이터는 LTV 데이터라고 합니다. 즉 데이터를 조회할 때마다 매출이 달라질 수 있다는 의미죠..

이렇게 되면 현재가 2024년 7월인데 2024년 5월 데이터를 5월에 조회했을 때랑 지금 조회할 때랑 큰 매출 차이를 보이게 됩니다.

머리가 아파집니다...

그래서 집약형 데이터를 API로 소싱 및 적재를 할 때 30일 정도치의 데이터를 매일 갱신해줘야 합니다.

예를 들면 집약형 데이터를 매일 30일 치 데이터를 소싱하고 기존 DB에 적재된 30일 치 집약형 데이터는 삭제하고 append 하는 방식입니다(SKAN aggregated performance API 도 동일한 로직으로 해주시면 됩니다)

SKAN API 는 Total Revenue 환율이 USD 데이터만 줍니다.. 처리하실 때 환율 데이터랑 결합해서 원화로 계산을 해야 되는.. 번거로움이 있어요..

또한 timezone 관련해서도 중요한데요 아래 가이드를 보시면 UTC only 라고 되어 있습니다(KST로 맞춰야 되는데..)

앱스플라이어 가이드

SKAN aggregated performance report API를 호출해 보면.. KST로 바꿀 수 있는 형태인지 확인해 봤는데 %y-%m-%d

형태로 데이터를 줍니다... 이상해서 다른 문서들에 뭔가 추가 정보를 얻을만한 것들이 있는지 문서를 찾아봤습니다.

앱스플라이어 API reference

AppsFlyer의 SKAdNetwork(SKAN) 개요 대시보드 가이드 내에는 메타, 구글 SKAN 데이터는 예외적으로 설정된 타임존을 따른다고 되어있습니다. API 문서에는 UTC only라고 되어 있어서.. 난감했던 경험이 생각납니다.

앱스플라이어 가이드

GA4 데이터 수집하기

GA4 빅쿼리는 실무에서 쓰고 있는 조직이 있나 싶을 정도로.. 사용하기가 좀 꺼려집니다.

원시데이터라서 데이터 가공의 자유도가 엄청나게 높지만.. 집계를 하는 입장에서는 굉장히 머리 아픕니다. 정합성을 어디다가 맞춰야 되는지..(아래 이전에 발행한 글 참고)

빅쿼리에서의 GA4 데이터 활용 현실: 기회와 치명적인 문제점

빅쿼리에서의 GA4 데이터 활용 현실: 기회와 치명적인 문제점

GA4 데이터를 빅쿼리로 보내면 뭐든 다 해결될 것 같은 이야기들이 많지만 실상은 그렇지 못합니다. GA4 인터페이스와 차이가 많고 많은 데이터 용량으로 ETL 과정으로 생각보다 리소스가 많이 듭

botongsaram.tistory.com

그래서 광고 데이터 성과를 집계할 때는 특별한 이유가 없다면 GA4 API 데이터를 소싱하는 게 정합성 의심의 여지가 없기 API 데이터를 활용하는 편이 좋다고 생각합니다.

API 호출 방법은 구글링 해보시면 쉽게 찾아보실 수 있습니다.

GA Data API

GA4 데이터는 진짜 샘플링을 주의해야 되는데요

보고서 만드시다 보면 오른쪽 상단에 있는 샘플링된 탐색 분석에서 더 자세한 결과를 누르지 않으면.. 샘플링된 데이터만 보게 되므로 정합성을 맞춰보실 땐 더 자세한 결과를 선택해줘야 합니다.(굉장히 번거로움)

그런데.. 데이터 조회 범위가 넓으면 샘플링된 보고서 밖에 확인할 수 없는...

GA4 보고서

GA4 API 도 직접 호출해 봅니다.

smapling_metadata 영역을 보시면 꽤 많은 양의 데이터가 샘플링 돼버립니다.

GA4 API 호출 결과

Query Explorer(링크) 도 조회해 봅니다.

여기서도 데이터 조회 범위가 넓으니 샘플링된 것 같아서 구글 측에 문의해 보니 맞다고 확인했고 추후에 Query Explorer의 이슈는 해결하겠다고 합니다.

Query Explorer 를 활용한 GA4 API 호출 결과

이런 이슈로 GA4 API를 샘플링되지 않을 정도의 날짜 범위로 API를 호출해서 적재를 하는 것이 좋습니다.

여기까지 마케팅 데이터 수집 자동화에 대해서 알아보았고 다음 편에서는 인사이트 도출을 위한 데이터 전처리 방법에 대해서 알아보겠습니다!

빅쿼리에서의 GA4 데이터 활용 현실: 기회와 치명적인 문제점

알랭드보통 사람 — Mon, 20 May 2024 10:54:49 +0900

GA4 데이터를 빅쿼리로 보내면 뭐든 다 해결될 것 같은 이야기들이 많지만 실상은 그렇지 못합니다. GA4 인터페이스와 차이가 많고 많은 데이터 용량으로 ETL 과정으로 생각보다 리소스가 많이 듭니다. 그럼에도 불구하고 빅쿼리를 쓰는 이유가 뭘까요?

GA4 빅쿼리네 데이터 Export 하는 기능

GA4 데이터를 빅쿼리로 활용하면 좋은 점

데이터 샘플링(GA4 인터페이스에서의 데이터는 샘플링이 되어있습니다)
일부 측정항목과 측정기준은 시스템에서 허용하지 않아서 결합해서 보기 어려움
데이터가 너무 많아서 상품 이름 같은 많은 측정 기준들이 (기타)라는 명칭으로 숨겨짐
유저 아이디별로 추출할 수 없고 집계된 계산만 추출 가능
데이터 카디널리티
- GA4 보고서를 보면 분석 범위에 행이 많으면 데이터 카디널리티 발생
- 이로 인해서 동일한 차원을 사용하는 표준 보고서와 다른 값이 나올 수 있음

데이터 카디널리티란?
카디널리티는 측정 기준 고유값의 개수.
하나의 측정기준에 얼마나 많은 고유값이 있는지를 의미함
예를 들어, 성별 측정기준은 남성, 여성으로 두 가지 값만 가지고 있으므로 카디널리티가 낮음, 반면 마케팅 데이터를 기준으로 캠페인차원(utm_campaign) 을 기준으로 측정기준을 가져가면 카디널리티가 높은 것

GA4 데이터를 빅쿼리로 사용한다면 판도라의 상자를 여는 것

일단 구글 애널리틱스 인터페이스와 데이터는 안 맞습니다. 아래는 공식문서상에서도 불일치가 있다는 것을 언급하고 있습니다.

[GA4] Compare Analytics reports and data exported to BigQuery(링크)

ga4 bigquery discrepency

GA4와 Bigquery의 불일치를 검색하면 상당히 많은 문서들이 나옵니다

차원데이터를 Break Down 하면 할수록(카디널리티가 높으면) (other)로 집계되기도 합니다.

특히 GA4 빅쿼리 데이터를 가공하다 보면 어? 뭐지? 하는 현상들이 있는데 대표적인 하나의 케이스를 공유해볼까 합니다. 바로! 빅쿼리에 저장되는 GA4 데이터에는 구글 관련 트래픽에 가장 큰 문제가 있다는 것입니다ㅜㅜ

gclid 파라미터(구글 애즈 캠페인으로 들어온 트래픽이라는 의미)가 있는 세션이 시작되었을 때 빅쿼리는 utm_medium, utm_campaign 파라미터를 (organic)으로 기록해 버립니다

다시 말하면 구글 애즈로 들어왔다는 데이터라고 식별은 되지만 캠페인 명이 증발해 버리는 현상입니다.(아래 쿼리 참고)

소스 = google
매체 = Organic
캠페인 = (Organic)

빅쿼리 RAWDATA 에 구글 캠페인명이 없음

with events as (
      select
        -- DATE(datetime(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) as date,
        cast(event_date as date format 'YYYYMMDD') as date,
        -- unique session id
        concat(user_pseudo_id, (select value.int_value from unnest(event_params) where key = 'ga_session_id')) as session_id,
        user_pseudo_id,
        (select value.int_value from unnest(event_params) where key = 'ga_session_id') as session_start,
        if(
              (select value.string_value from unnest(event_params) where key in ('campaign_id', 'campaign', 'source', 'medium', 'term', 'content', 'gclid', 'dclid', 'srsltid') and value.string_value is not null limit 1) is not null,
              (
                select as struct
                  (select value.string_value from unnest(event_params) where key = 'campaign_id') as manual_campaign_id,
                  (select value.string_value from unnest(event_params) where key = 'campaign') as manual_campaign_name,
                  (select value.string_value from unnest(event_params) where key = 'source') as manual_source,
                  (select value.string_value from unnest(event_params) where key = 'medium') as manual_medium,
                  (select value.string_value from unnest(event_params) where key = 'term') as manual_term,
                  (select value.string_value from unnest(event_params) where key = 'content') as manual_content,
                  (select value.string_value from unnest(event_params) where key = 'gclid') as gclid,
                  (select value.string_value from unnest(event_params) where key = 'dclid') as dclid,
                  (select value.string_value from unnest(event_params) where key = 'srsltid') as srsltid
              ),
              null
              ) as collected_traffic_source,
        event_timestamp,
        stream_id,
        (select value.string_value from unnest(event_params) where key = 'device_category') device_category,
        event_name,
        ecommerce.purchase_revenue_in_usd  as purchase_revenue_in_usd,
        case 
          when event_name = 'purchase'
          then 1 else 0 end AS purchase

      from
        `테이블명`
      where
         _TABLE_SUFFIX >= '20231001' AND _TABLE_SUFFIX <= '20231001'
        -- starting from 20231102 the sessions_start and first_visit events don't need to be excluded anymore
        and (select value.string_value from unnest(event_params) where key = 'source') = 'google'
)

select * from events
order by session_id

이 현상을 해결하려면 UTM 파라미터를 자동 태깅(gclid)을 대신해서 사용하거나 URL에 커스텀 파라미터를 붙여서 해결할 수 있긴 합니다.

Page Referrer에 담긴 gclid를 모아서 빅쿼리의 데이터를 수정해 줘야 됩니다.
여기서 한 가지 조건이 있는데
- 유저가 세션 안에서 2개의 페이지 뷰 이벤트를 가지고 있어야 합니다.
- 왜냐하면 사용자가 광고 클릭 후 랜딩 페이지에 도착하고 이후 추가 페이지를 탐색할 경우, 첫 번째 페이지(랜딩 페이지)에서의 referrer에 gclid가 포함되어 기록될 가능성이 높기 때문입니다.
따라서 GA4 Custom Dimensions을 통해서 ga_session_id, gclid를 구글 태그매니저(GTM)로 잡는 방법을 사용하면 됩니다.
이렇게 셋팅을 했다면 GA4 API를 통해서 sessionCampaignName, sessionSourceMedium, customEvent:ga_session_id, customEvent:gclid 를 구글 스프레드시트나 빅쿼리에 테이블을 만들거나 혹은 GCF(Google Cloud Function)을 활용해서 빅쿼리 테이블 만들어서 GA4 빅쿼리 테이블과 JOIN 을통해 이런 현상을 해결 해볼 수 있습니다.

결론

유저 레벨 분석이 아닌 마케팅 성과를 집계하기 위한 목적(ROAS, CPA 등과 같은 성과지표)으로 GA4 데이터를 활용하고자 한다면 Bigquery Export 보다는 Google Analytics Data API 를 활용해서 일별로 (날짜, 소스, 매체, 캠페인 차원과 필요 지표들) 내부 DataWarehouse에 저장해서 활용하는 방식이 더 효율적일 수 있습니다.

참고로 Google Analytics Data API 를 활용한다면 집계된 데이터를 받아오기 때문에 Total Users와 같은 유니크한 집계값 (Count Distinct)를 해야 되는 지표는 제외하고 이벤트 단위(구매, 회원가입 이벤트 수)의 지표만 활용해야 합니다.

※ GA4 API 데이터 적재하여 사용할 때 user 집계 measure를 사용하면 안되는 이유

예를 들어 4명의 유저가 우리 사이트에 2024-01-01 ~ 2024-01-03 기간 동안 방문했습니다.(로우 데이터)

event_time	user_id
2024-01-01	U1
2024-01-01	U2
2024-01-01	U3
2024-01-02	U1
2024-01-02	U2
2024-01-03	U1
2024-01-03	U3
2024-01-03	U4

일별 Total User를 집계해 보면

event_time	user_id
2024-01-01	3
2024-01-02	2
2024-01-03	3

전체 기간의 Total User를 집계해 보면

event_time_range	unique user count
2024-01-01 to 2024-01-03	4

일별, 기간별 집계했을 때 유니크 사용자수는 완전히 다릅니다. (DAU, MAU 개념과 동일) 일별 테이블을 다 더해서 집계를 해서 사용하시면 쓸모없는 지표가 되어버리기 때문입니다.

그래도 유저레벨 단위로 혹은 GA4 인터페이스에서 처리 못하는 방식의 데이터 가공이 필요하다면 위의 케이스를 반드시 고려해야 될 뿐 아니라 분석 단위(dimension) 별 유저수, source, medium별 attribution의 차이를 염두하고 빅쿼리를 사용하셔야 합니다.

풀스택 마케팅 컨설팅펌 마티니아이오

Martinee

브레이즈에 대한 마티니의 높은 이해도를 바탕으로 이탈 유저 대상 LMF 실험을 통해 최적의 크리에이티브를 찾아 대조군 대비 ~93% CVR 상승을 경험했고, OS, Segment별 성과에 따른 후속 액션을 도출

martinee.io

마티니 링크드인

https://www.linkedin.com/company/martinee

Martinee (마티니아이오) | LinkedIn

Martinee (마티니아이오) | LinkedIn 팔로워 591명 | 마티니(Martinee)는 ‘Marketing Intelligence People’의 약자로 웹/앱 서비스 성장에 필요한 Growth, CRM, Performance Marketing을 풀 스택으로 지원합니다. | 앱스플라

kr.linkedin.com

앱스플라이어(AppsFlyer) MMP 제대로 사용하고 있는걸까? 데이터 사각지대 대응 솔루션 ft. 데이터 락커

알랭드보통 사람 — Fri, 26 Jan 2024 16:16:57 +0900

앱 마케팅의 성과 측정을 위한 방식과 데이터의 해석은 쉽지 않습니다.

아마 경험이 있으시다면 내가 성과를 제대로 측정하고 있는지 다른 데서도 이렇게 하는지 앱 성과 측정을 잘하는 곳은 어떻게 하는지 많이 궁금해하실 겁니다.

특히 개인정보보호 이슈로인해 앱 마케터들이 필요한 성과 측정 지표에 구멍이 뚫리기 시작했었죠

이를 위해 MMP들은 이를 보정하기 위해 굉장히 많은 기술로 앱 성과를 측정할 수 있도록 보완해주고 있습니다.

하지만 이를 제대로 사용해야만 데이터 사각지대를 피할 수 있습니다.

데이터 사각지대란?

"데이터 사각지대는 마치 안개가 짙은 도로에서 운전하는 것에 비유할 수 있을 것 같습니다.

안개가 짙으면 운전자는 도로의 일부만 볼 수 있으며, 나머지는 안개에 가려져 보이지 않습니다.

마찬가지로, AppsFlyer의 로우데이터 리포트에서는 일부 데이터가 제한되거나 가려져 있어 전체적인 상황을 완전히 파악하기 어려운데 이를 데이터 사각지대라고 표현합니다.

어떤 현상이 발생하는가?

모바일 앱 성과를 측정할 때는 플랫폼 및 매체사의 개인 정보 보호 및 그에 따른 데이터 공유 정책에 기반한 로데이터 리포트 제한으로 인해 데이터를 제공받지 못하는 현상이 발생합니다.

로데이터 리포트 제한이란?

전환(설치 및 재참여) 및 제한 광고 네트워크가 기여한 관련 인앱 이벤트가 제한되어 앱스플라이어에서 데이터를 내려받으면

Media Source 필드는 restricted 로 채워지고 어트리뷰션 필드는 비어 있거나 null로 채워집니다

앱스플라이어 로우데이터

또한 데이터 보존 및 삭제 정책에 따라 유저 레벨의 데이터는 AppsFlyer에 의해 제한된 기간 동안 보존되고 보존 기간이 끝나면 사용자 이벤트는 원래 미디어 소스 대신 유기적(organic) 소스로 변경됩니다.

이외에도 여러 제약 조건이 있어서 공식문서를 살펴보시길 권장드립니다.

리타겟팅 어트리뷰션과 UA 어트리뷰션 데이터를 통합할 때 인앱 이벤트 성과 중복이 생길 수 있는 점

캠페인의 re-engagement window 동안 퍼포먼스를 평가하기 위해서 인앱이벤트와 세션은 UA(user acquisition) 과 retargeting의 media source에 중복 집계됩니다
이를 고려해서 리포트를 csv로 내려받은 후 마케터는 데이터를 가공해줘야합니다. (데이터를 내려받는데 시간이 약간 소요됩니다.. 리포트를 가공하는데 앱 마케터들은 매일 반복된 작업으로 오전시간을 소비합니다. 이를 자동화하고 마케터가 분석에 좀 더 몰입할 수 있게 마티니는 마케팅 데이터 파이프라인 구축에 도움을 드리고 있습니다)

앱스플라이어 로우 데이터 Export

인앱 이벤트 성과 중복이 된다는 개념을 살펴보자면

아래 이미지 처럼 리타겟팅 캠페인으로 유입된 유저의 데이터는 UA, RT(retargeting) 리포트에 중복으로 기록됩니다.

앱스플라이어 : 리타겟팅 이벤트의 중복 어트리뷰션

데이터를 다운 받으시면 아래 이미지와 같은 컬럼을 확인할 수 있습니다.

앱스플라이어 리포트 예시

위와 같은 현상을 보완할 수 있는 앱스플라이어의 기능으로는 무료로 사용가능한 데이터 락커의 코호트 애널리틱스 입니다.

데이터 락커 : 코호트 분석 리포트 샘플

데이터 락커 구독(유료) 없이도 제공되는 리포트 항목 중 하나(추가 비용 없이 리포트 사용 가능)
이 데이터를 활용하려면 약간의 개발 지식이 필요합니다.
UA, 인스톨, 리타게팅, 리어트리뷰션, 리인게이지먼트와 관련 인앱이벤트 데이터가 포함됩니다
앱스플라이어 어드민에서 데이터락커 기능을 활성화하여 Cloud Stroage(Google Cloud Storage or AWS S3)에 데이터 보내는 설정을 하고 이를 DW(Data Warehouse)에 저장을 하여 분석에 사용하셔야 합니다.

Cloud Stroage

이 데이터는 최근 1년 동안 기여된 사용자 데이터를 담고 있고 위에서 설명드린 로데이터 리포트 제한이슈로 발생하는 데이터 사각지대를 보완하여 로데이터의 대안으로 사용할 수 있습니다.
저장을 한 뒤에 성과를 올바르게 집계하기 위해 전처리를 하여 BI 툴을 활용하여 자동화된 대시보드를 구축할 수 있습니다.
- Unify 의 경우 is_primary_attribution 필드를 TRUE 혹은 NULL 로 사용
- UA 의 경우 conversion_type = install 로 사용
- RT(retargeting)의 경우 conversion_type = re-engagement 또는 re-attribution으로 사용

하지만 단점도 물론 존재합니다.

iOS의 경우(마케터를 힘들게 하는 주범), 앱스플라이어 어트리뷰션과 SKAN 어트리뷰션 데이터를 통합할 때 중복이 생길 수 있는 점
SSOT가 적용이 안되는 점
- SSOT는 앱스플라이어 Overview 대시보드에서만 확인 가능합니다..ㅜㅜ
- 하지만 앱스플라이어가 유저의 니즈를 모를리 없죠. 앱스플라이어에서 이 기능을 고려한 리포트를 준비중이라고 들었네요

Single Source of Truth
앱스플라이어가 측정한 어트리뷰션 데이터와 SKAN을 통해 측정한 어트리뷰션 데이터를 통합할 때 중복을 제거할 수 있는 솔루션이 SSOT 입니다.

이번 글은 앱스플라이어를 사용하면서 데이터 사각지대에 빠지지 않기 위한 방법으로 데이터 락커 코호트 분석 기능을 소개해드렸습니다.

다음번에도 앱스플라이어를 제대로 사용할 수 있게 도움을 드릴 수 있는 글을 작성해보려 합니다.

풀스택 마케팅 컨설팅펌 마티니아이오

https://martinee.io/

Martinee

마티니의 글로벌 앱마케팅에 대한 경험은 카카오웹툰의 해외리젼에 많은 도움을 주고 있습니다. 또한, 소재에 대한 이해를 바탕으로 한 기획/제작과 글로벌 대응에도 내재화된 조직들이 있어,

martinee.io

마티니 링크드인

https://www.linkedin.com/company/martinee

Martinee (마티니아이오) | LinkedIn

Martinee (마티니아이오) | LinkedIn 팔로워 437명 | 마티니(Martinee)는 ‘Marketing Intelligence People’의 약자로 웹/앱 서비스 성장에 필요한 Growth, CRM, Performance Marketing을 풀 스택으로 지원합니다. | 앱스플라

kr.linkedin.com