[사이드프로젝트][사이드176] 기획 피드백 3차 + ERD개념과 테이블 PK,FK 설정 + GA 세팅 및 데이터 정량 분석

기획 피드백 3차 

- 기존 전환 모달 기획안 UI측면의 가시성을 위해 아코디언 효과로 처리
- 그 외 세부사항 정리
=> 기획은 서비스 시작부터 끝까지 끊임없이 케어해야 하는 걸 체험하였기 때문에 요즘 많은 기업에서 요구하는
     기획자의 PM 겸업이 어찌보면 당연하다 생각되었다.
 
 

테이블별 PK,FK 설정

사실 실무에서도 안해본 내용이라 너무 재밌고 유익한 작업이었다.
- 목적 : 개발자가 테이블을 만들 때, 유저 관점 시나리오에서 어떤 연결 흐름이 있는지 바탕으로 테이블을 구성하기 위함
 
- Q.가장 필요한 테이블이 뭘까?
A. 기획서를 기반으로 보았을 때,
1) 회원가입이 있으므로 회원  T
ㄴ 회원ID, 닉네임 등 세부 기획 항목
 
2) 지도 정보를 기반으로 스팟을 제공하기 때문에 스팟T
ㄴ (지도의 기본적인 사항) 위도, 경도, 건물명
ㄴ (운영중인 사항) 스팟 업로드 일자, 스팟 주소, 스팟명  
 
스팟의 상세 정보를 제공하므로 스팟 T
ㄴ(이미지 기준 기능)과 (줄글 기준 기능)과 (스팟 내 핵심 서비스)를 어떻게 구분할까? --> T를 나누자
ㄴ (+) 개발자 관점에서 특정 테이블에 데이터를 몰아 넣으면 중복 발생 여지가 늘어나므로 분할하는 것이 좋음
3) 스팟을 줄글 기준으로 제공하기 위한 스팟 정보 T
4) 스팟을 이미지 기준으로 제공하기 위한 스팟 사진T 
5) 스팟의 핵심 서비스를 제공하기 위한 스팟 핵심 서비스 T
 
=> 상세하게 테이블 구조를 만드는 것이 아닌 어떤게 핵심 파라미터인지를 설명하는 게 자료의 핵심이란 걸 배웠다.
너무 멀리까지 생각해서 셀프 부담감 부여하지 않기,,
 
 
 

테이블 선정에 따른 기획서 기반 PK, FK 설정하기

- 기본으로 ERD(개체 관계도)의 구조는 아래와 같다

명칭	ex)	명칭 설명
개체(Entity)	스팟	독립적 대상, 관리 필요 대상
속성(Attribute)	명칭, 주소,오픈일	개체의 속성, 유일무이 함
개체 인스턴스(Entity Instnace)	{명칭 : A가게}, {주소 : 서울시 A구 a동}, {오픈일 : 2023-10-05}	개체 내의 실제 속성 세부 정보

 

• PK : 해당 T의 고유 식별자
• FK : 타T와 관계를 맺는 식별자

기획 관점에서 주목할 것은 PK이다.
PK,FK는 통상적으로 ID(uuid)값이 선정된다.

* GUID라는 글로벌 유니크 식별자로 보통 ID를 작성하며, uuid는 중 한개의 개념으로, 중복될 가능성이 현저하게 낮은 식별자이다. 

통상SQL로 데이터를 설계하는데 ERD에서 FK 속성을 통해 개체 관계를 표기하고, 관계된 FK는 PK값으로 치환이 된다.

출처 : https://brunch.co.kr/@famelee/112 ,  https://sy-log.tistory.com/61

 
따라서 우리의 테이블 정의 같은 경우에는,
FK속성을 통해 개체 관계가 표시되는 경우는 스팟T에서 파생된 T들의 내용이므로 아래와 같이 정의 하였다.
간단.. 하다!

T명	PK	FK
스팟 T	id
스팟 정보 T	id	id
스팟 사진 T	id	id
스팟 핵심 서비스 T	id	id

 
=> 기획 입장에서 erd의 정규화 과정은 굳이 알 필요가 없으며, erd를 만들 때 개체가 어떻고, 속성은 어떻고 그런것 까지는 알 필요가 없다는 것이다.(물론 알면 좋지만 필수 지식이 아님)
 
 
 

GA 사용의 이유

- 사용자의 활동, 매출, 이벤트 추적 등 다양한 데이터를 수집하고, 이를 통해 앱의 성능을 평가하고 개선하는 데 도움됨

 

GA 리포트 구조

- 기본 구조 : 계정 - 속성 = 보기

• 계정 : ID, 속성에 대한 권한을 부여받는 사람
• 속성 : 데이터 저장공간
  • 저장공간 속 원하는 결과를 위해서는 필터 작업이 필요함
• 보기 : 속성을 기반으로 만들어진 개별 단위 보고서
  • 필터 기준에 따라 유입된 데이터를 기반으로 필요한 정보를 추출함

출처 : https://yozm.wishket.com/magazine/detail/729/ 

 

 

GA 태깅을 위한 선행 지식

진짜 뭐라는지 모르겠어서 공부한 것을 적어본다.
 
이벤트 : 유저 행동 식별자
EX_ 유저가 클릭한 버튼의 이벤트를 추적함 => 이벤트 : 버튼 클릭


매개변수 : 함수나 메서드 실행을 위해 필요한 정보 제공하여 식별의 기준이 됨 , 함수 내에서 사용되는 변수
EX_ 유저가 클릭한 버튼의 이벤트를 추적함 => 파라미터 : 버튼의 색, 버튼의 위치

(+) 파라미터 : 함수나 메서드에 전달되는 값으로 호출시 전달됨
=> ga에서는 파라미터나,, 매개변수나 걍 다 매개변수라고 인지하면됨

 
클래스 : 이벤트를 유저 행동 유형/ 이벤트 유형으로 분류하여 그룹화 함 (보통 페이지별로 클래스를 선정함)
EX_ 유저가 클릭한 버튼의 이벤트를 추적함 => 그룹 : 버튼을 누르는 행위
 
 

GTM이란

- Google Tag Manager
- 웹사이트나 앱에서 태그를 관리하는 도구
=> 추가 논의 끝에 사용 도구가 변경되었다.
Q. GTM태깅 하지 않기로 정한 이유
A.Firebase에 연동되어 있으므로 Firebase GA 태깅 가능하기 때문이다.

 

그래서 더 자세하게 알아본 Firebase

Firebase
- Mobile OS, 웹서비스에서 DB 관련 코드없이 DB사용을 가능하게 함
- Google Analytics는 Firebase의 일부로 포함되어, PRODCUT에서 사용자 동작 및 성과를 추적하고 분석하는 SW
- 사용자 속성은 50개까지만 등록 가능

 

Firebase의 내장된 Analytics 기능을 통해 앱에서 발생하는 이벤트 및 사용자 동작을 추적하고 데이터를 수집할 수 있음

• Cloud FireStore - 안드로이드, ios, 웹서비스에서 데이터베이스 관련 코드 없이 데이터베이스 사용
• Firebase ML - 텍스트 인식, 얼굴 인식 등 머신러닝 기능을 모바일 기기에서 사용할 수 있게 하는 SDK (Software Development Kit), 웹 지원 안함
• Cloud Functions - 파이어베이스로 구축한 서버에 사용자가 작성한 코드를 실행하는 기능 제공
• Cloud Storage - 이미지 파일과 같이 데이터 저장 기능 제공
• Hosting - 웹서비스 호스팅
• Authentication - 여러 인증로직을 사용자에게 제공
• RealTime Database - DB 에 데이터가 실시간 반영되고 사용자에게 동기화 됨. 다른 사람이 작성한 글이나 수정한 글을 실시간 확인 가능

출처 : https://velog.io/@rayong/Firebase-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80 

 

 

(240101) 엄청 자세한 블로그 찾음 애초에 이거 보고 할껄^.ㅠ

https://brunch.co.kr/@minwoo/24 

Firebase Analytics 시작하기

Firebase는 기본 GA용 이벤트/ 옵션 이벤트로 자동 기록한다. 그리고 그에 대한 내용은 아래와 같다.

- 자동 화면 추적 기능
GA는 화면 전환(Activity)가 발생하면 자동으로 매개변수와 id가 태그되어 로그와 보고서를 남긴다.

Activity = 화면 전환 그룹			설명
이벤트	Screen_view 등 항목 https://support.google.com/analytics/answer/9234069?visit_id=638379394329708726-841956290&rd=2		화면 전환 발생 시, 새 화면 식별용 이벤트 명칭 기본 옵션
이벤트 식별을 위한 태그 항목 (매개변수)	menuViewController / MenuActivity   = firebase_screen_class	해당 화면 id = firebase_screen_id	Screen_view를 식별하는 각 고유 속성 옵션

 
- 수동 화면 추적
자동 추적 대상 외에 특정 이벤트를 추적하고 싶을 때, 원하는 이벤트을 선정하여 SCreen_View이벤트로 치환하여 
코드를 입력해 두면, 자동으로 로그와 보고서를 남긴다

출처 : https://gyuios.tistory.com/283,https://support.google.com/analytics/answer/9234069?visit_id=638379394329708726-841956290&rd=2  

 

 

그래서 FIREBASE에서 보고 싶은 이벤트를 항목화 하자

- 이게 뭔지 모르겠어서 전혀 감이 안왔다... 대표적인 양식하나를 기재해본다
FirebaseAnalytics.Event (google.com) 
[ 이벤트 정리할 때 전제로 생각하며 좋은 사항] 
- 이벤트 목적 정리 => 이 내용은 QA TEST 시나리오 케이스가 될 수 있다
 
[ 컬럼 4가지 ]
- 이벤트명, 트리거, 파라미터, 파라미터값

• 이벤트명 : 비개발자가 보기에 명시적인 ACTION명
  • EX_필터의 HIT이벤트 확인이 목적이므로 이벤트명 = Filter_btn_hit
• 트리거 : 이벤트를 전송하는 사용자의 ACTION
  • EX_ 필터의 HIT이벤트 확인이 목적이므로  트리거 = 사용자가 필터버튼을 터치
• 파라미터 : 이벤트 발생시 추가적으로 보고자하는 데이터
  • EX_결제 발생시 파라미터 = 상품명, 상품 카테고리, 할인쿠폰 정보
• 파라미터값 : 파라미터의 종속조건
  • EX_결제수단이 파라미터라면 파라미터값 = 토스페이

참고 :  Firebase 이벤트로 GA에 데이터를 쌓아보자 (brunch.co.kr)
 
 
=> 우리 팀은 수동 화면 트래킹을 위한 이벤트 정의를 위와 같이 하지 않았다.
다행스럽게도 동료 기획자가 이 작업을 실무해서 해본 적이 있어서
리드를 따라갔다 (감사합니다) 이 과정의 확인 작업은 이러했다.
 
[ 개발단에서 확인해준 내용 ]
- 이벤트 정의를 하지 않은 경우 매개변수명 그대로 리포트에 보고됨
 
1. firebase_screen_class : 이벤트 트리깅(발생) 이후 최종 화면

 
2. firebase_previous_class : 이벤트 트리깅(발생) 직전 화면

 
- 이렇게 TEST 결과를 공유 받았고 해당 지식 기반으로 이벤트를 항목화 하였다.
우리가 사용한 컬럼 구분자는 다음과 같다.
 

• 이벤트

1) Firebase에서 정의하는 이벤트명을 기재

• screen_view
• select_content

• 실제 영역(실무진 구분용) 

2) 서비스 화면 명(DEPTH1) : PAGE별 분류대로 기재함
3) 서비스 화면 명(DEPTH2,3) : 팝업, 모달인 경우를 기재함
4) 영역 : 세부 서비스명을 기재함
5) 트리거(=Content_type 명칭) : 지표로 유형화(사용자 상호작용 행위)하여 기재함 
- 기본적인 GA 지표 유형 : 리텐션, 클릭 이벤트, 이탈률, 세션 시간, 페이지뷰, 사용자수, 설치자수
  

이벤트 종류 = Firebase에서 

 

• 매개변수 (Firebase 양식 기반) = 핵심은 실무진이 데이터 들어왔을 때 한번에 알아보도록 기재하는 것

6) SCREEN_CLASS (EX_홈, 서비스 페이지)
ㄴ 사용자가 상호 작용하는 앱 화면의 클래스
 
7) SCREEN_NAME (EX_마이페이지, 개인정보 변경(비밀번호변경))
ㄴ 사용자가 상호 작용하는 앱 화면의 이름
 
8) ITEM_NAME (EX_뒤로가기, 운영시간대 열기)
ㄴ 특정 항목이나 객체의 이름 <= 우리는 버튼명 기반으로 작성함
 
9) PLACE_UUID : 서비스 핵심이 PLACE이므로 선정, 옵셔널로 데이터를 받아야 하는 매개변수
ㄴ 특정 항목이나 객체의 고유 식별자
 

=> 태깅과정에서 F/E개발자 동료의 추가 확인 사항이 발생했다.

1)

우리가 위에 정의한 내용 중 컬럼 구분자에 Content_type 정의가 필요한 것을 알게되었다.근데 이 내용은 트리거 항목이랑 동일해서 영어로만 번역 추가 했다.

 

2)

특정 화면(우리는 지도)에서 클릭 개수는 확인이 가능하지만 어느 previous 시나리오로 인입되었는지는 확인 할 수 없다

 

3)

동료 개발자가

현재 previous screen을 매개변수로 사용하지 않는데, SCREEN_NAME에 대해 상세하게 기재(ex_a항목(b에서 진입))하는 것보다

previous screen을 매개변수로 사용하고 SCREEN_NAME을 간략 기재(ex_a항목)하는게 장기적으로 효율적인것 같다 제안을 해주셨다. 

동료 기획자는 ga를 사용한 경험이 있기에 장단점을 나열해주었다. GA 특성상 기본 리포트에서 한 가지 매개변수만 중심으로 보여주기 때문에 추가 매개변수를 도입할 경우 매번 필터링을 해야 한다.  이 이야기를 듣고 기본 리포트와 사용자 지정리포트를 추가 정리했다(본문 내용)

결국 우리는 동료 개발자가 제안한 내용대로 가기로 하였다. 이부분은 GA 강의들으면서 더 지식 확장을 해야될 것이다.필수적으로..

 4) granted는 어떤 옵션으로 도출된 결과인지 알 수 없다. 허용/비허용 두 범위만 확인이 된다.

예를 들어, '한번 허용' '항상 허용'은 엄연히 다르지만, GA에서는 알 수 없다.

결국 허용 하나로 ITEM_NAME을 수정

=> 왜 GA지식이 필요한지를 깨닫는 작업이었다. GA에 대한 기본 지식이 있어야 인하우스에서 더 유의미한 데이터를 받을 수 있고, 이를 기반으로 기업 공고에서 그렇게 외치는 데이터 기반 사고를 할 수 있겠구나를 느낄 수 있었다.