Alpha Push Audience CRM 0.7 PRD 리뷰

감기인 거죠 지아님? 기다려주세요. 이거 에어컨 좀 끄는 게 좋을까요 혹시? 어..아니에요. 괜찮아요? 너무 더워진 것 같아요. 네. 아까 상재 선생님이 있잖아요.

수정 상재 상재. 그냥 수정 아예 안 부르는 중 하나. 소송을 비쎄서는 양을 주어야 했는데 안 부르는 중. 죄송한데 6층을 잡으신 거 맞나요? 안 잡혔나요? 죄송해요. 제가 그... 어 6층이다. 죄송해요. 아 죄송합니다. - 나 더운 거 아니야? 다 아파? - 코로나는 아니야.

- 코로나는 아니야. - 코로나는 아니야. - 어? 진짜요? - 조심하셔야 돼. 어 진짜 조심해겠네. 이 아픈 사람이 좀 나은 거 같아서. 그런데? - 오케이. - 오케이. 다 모였는지 체크해볼게요. 네 다 모였고요.

오늘 알파 푸시 오디언스 CRM 개발 버전 0.7 PRD를 리뷰를 할 거고 오늘 만약에 의사결정이 다 진행이 되면 이거 버전 1.0으로 만들고 이제 최종 배팅 영역으로 이제 던을 할까 합니다. 그래서 사전에 코멘트를 달아주신 분들도 있고 다들 1차 리뷰는 다들 하셨던 상황이라서 코멘트 위주로 다시 한번 보셔도 좋고요 시간을 제가 10분 정도 드릴 테니까 다시 한번 스키밍 해보시고 추가 질문 있으시면 남겨주시면 감사하겠습니다

시작해볼게요 지금 11시 4분이니까 11시 14분에 시작하는 걸로 할게요 이게 아마 버전이니까 제가 계속하면서 처음에 보셨던 내용이랑 조금 달라지는 부분도 있거든요 그러니까 처음부터 다시 한번 읽어보시는 것을 권장드립니다 네. 네, 해파카 통해서 일단 넣어놓긴 했는데

도움이 안 되면은 빼는 것도 고려하겠습니다 오히려 헷갈리면은 빼는 게 나을 수도 있을 것 같아요 그럼 일단 제외하고 제외하고 네, 그게 나을 것 같아요 감사합니다.

감사합니다. 다 부숴었을 것 같고요

시간이 더 필요하신 분이 있다면 손을 들어주시기 바랍니다 5분 더 드릴게요

19분입니다. 5분 지났고요. 시간 더 필요하신 분 있으면 손 들어주세요. 없으면 시작하도록 할게요. 코멘트 위주로 살펴볼 거고요. 흐름에 맞춰서 진행하는 게 좋을 것 같아서 위에서부터 진행하도록 하겠습니다. 프로그램 부분은 없고요. 다들 문제의식에 동의하시는 것 같고 오디엄스 개념 부분에서 용어체계 관련한 코멘트 빠르게 살펴보고 넘어갈게요. 보셨을 테니까 다 제가 브리핑할 필요는 없을 것 같고

동훈님께서 의견 주신대로 저희는 오디언스로 통일해서 쓰려고 하는데 동적이랑 정적인 구분이 필요하다고 하면 일단 클라비오를 생각해보면 얘는 생성시점에 이런 식으로 구분을 해놓긴 하거든요 그래서 같은 레퍼런스를 참고하면서 그렸기 때문에 비슷한 느낌이지 않을까 근데 사실 디자인상에서는 현재 정적이냐 동적이냐를 따로 태극값으로 구분하고 있지는 않을까 근데 이게 필요하면 넣으면 될 것 같긴 한데 어떻게 생각하시는지 다들 의견을 좀

듣고 싶습니다. 쉽게 생각하면 자동화 캠페인, 캠핑 같은 느낌 아닌가요? 리스트는 생성했을 때 한 번 정해지는 거고, 세그먼트는? 그럴까요? 이게 리스트로 생성됐지만 자동화 캠페인처럼 쓸 수도 있지 않을까요? 타겟군만 커스터마이징해서 세팅한 거고 얘네들한테 계속 자동화로 캠페인을 쓰고 싶다는 마케터의 니즈가 있을 수도 있다. 그럼 리스트랑 세그먼트의 차이가 뭔지 여쭤볼게요. 리스트랑 세그먼트는 지금 여기 보여지는 화면이랑 동일하게 생각하긴 했어요. 리스트는 굉장히 정적인 프로필이라서

처음에 생성을 할 때 시점에서 계산해서 자동화된 수식 하에서 모수가 나오는 게 아니라 마케터가 진짜 한 명 한 명 다 타겟팅해서 민우님, 도우님 이런 식으로 해서 정적이라는 표현이 직접 설정의 해석으로 보실 수도 있을 것 같아요. 저기서는 클럽 면역도 리스트를 그런 걸로 써요. 저도 저게 부분이 잘 안다는데

일단 얘네들 이메일 수집 팝업 같은 기능이 있는데 그 이메일 수집 팝업에 이메일을 입력한 사람의 리스트가 리스트로 만들어져 있고 그래서 경적이라고는 하나 바뀔 수는 있거든요. 워크플로우 안에 노드 중에서도 리스트에서 지금 트리거된 사람을 리스트에서 제거한다. 이런 노드가 따로 있어요.

리스트 수정에 대한 노드가 따로 있는데 그러면 리스트에 넣었다 뺐다를 자동화된 규칙이 아니라 진짜 목록으로 관리를 하려고 하는 개념인 것 같고요. 근데 그게 조금 잘 이해가 안 나요. 그리고 왜 반드시 나눠 놨는지 자체는 잘은 이해가 안 나요. 저도 도우님처럼 생각하고 있고, 근데 조금 고민을 해봤을 때 클라비우의 특징이 굉장히 글로벌한 서비스잖아요.

각 국가별로 타겟을 하거든요. 그래서 어떤 특정 회사, 굉장히 글로벌 서비스 회사가 한국과 일본과 미국을 타겟으로 이 CRM 도구를 쓴다고 하면 각 국가별로 수신동의에 대한 법령이 다 다를 것 같아요. 그렇기 때문에 애초에 각 채널별로 이메일이든 전화번호든 SNS든 이런 것들을 어떻게 수신동의 받을 건지에 대한 고민을 되게 많이 한 것 같거든요. 그래서 그 앞단에서의 커스터마이징 할 수 있는 요소가 굉장히 많아요. 그러다 보니까 이런 정적인 리스트 관리에 대한 니즈가 있었을 것 같다라고

생각은 해봅니다. 제 생각이에요. 이 부분은 이렇게 뭐 가도 괜찮을까요? 아니면 좀 더 얘기해 볼 부분이 있을까요? 그거 이거 보면 안 될 것 같아요. 월그런즈는 정확히 이해는 해야 될 것 같아요. 그게 오디언스 목록을 지금 맡은 푸시 쪽에서는 되게 중요한 부분인 것 같아서 그거는 추가로 이해해 주시면 좋겠습니다. 그래서 개발 과정에서는 이게 어떤 정리를 해야 되냐면 예를 들어서 저는 CSV 업로드 기능으로 풀어보려고 했던 거였거든요

생성 시점에 CSV 업로드라는 형태로 정적인 고정된 고객 타겟군으로 오디언스를 생성할 수 있다 까지 상정해놨는데 혹시 여기에 뭔가 반론이 있거나 조금 더 고민해야 될 요소가 있다면 알려주시면 고민해보겠습니다. 반대로 동적인 세그먼트라고 클럽에 명령한 오디언스에서는 실제 고객 목록이 노출되는 건 아닌가요?

계산을 해서 노출시킬 수 있을 것 같아요. 질문하신 게 그 시점에. 그 시점에. 맞아요. 그래서 코우트라고 보통 하잖아요. 그 시간대에 집계할 수 있는 고객의 명단을 볼 수 있습니다. 그럼 그 명단은 그 시점에만 유효한 건가요? 맞아요. 돌리면 계속 바뀌어요. 그럼 유효 시간이 어떻게 돼요? 그것도 정해볼 수 있을 것 같은데요. 일단은 팀 내에서 얘기를 할 때는 저희가 하루 단위의 배치 정도 생각을 하긴 했어요. 정해진 시간 동안에.

맞죠? 지아님? 그때 우리가 그렇게 얘기했었죠. 어떤 걸?

액티브 되어 있는 오디언스들은 모두 기본적으로는 하루 단위의 배치로 계속해서 스냅샷을 찍어 놓을 거고 다만 사람이 수동 계산을 할 수 있다. 그때마다 그런 부분도 스냅샷에 찍히긴 하겠죠. 근데 그 목록이 대상이 됐던 사람들의 리스트를 스냅샷을 찍어야 되는 건지 잘 모르겠는데 그러니까 하루 단위로 계속 그 목록에 해당하는 사람을 계속 확인하겠다는 거잖아요.

그 표는... 그래서 이게 계속 나올 주제인 것 같은데 맞아요 맞아요 그 지표를 어디서 오디언스 목록 자체에서 확보해야 되는지 소유에 대한 걸 계속 지금 얘기하는 건데 그걸 엄밀하게 구분을 해야 되는 거거든요 워크플로우의 지표체계 안에 들어있는 그 실행에 대한 지표들은 워크플로우가 가져가는 것 같고

그러면 이제 나머지는 뭘 가져가야 되냐는 데였을 해서 그 로고를 생각해봐야 될 것 같아요. 그게 특별한 게 없으면 사실 뭔가 계속 하루 단일 워치기를 돌릴 이유가 일단은 여기서 제가 다시 위로 좀 올라가 보면 풀고 싶은 문제에서 이렇게 쓰긴 했거든요. 기존에는 저희가 오디언스 조건을 일회성으로 조합해서 그냥 그때 한번 보고 그 성과를 그냥 바라봤던 것밖에 없다 보니까 지속적으로 CRM이라면 단발성이 아니라

누적 성과 개념으로 가야 되는 건데 결국 타겟팅되어 있는 고객들이 올바르게 성장하고 있는가가 그냥 제가 해석한 누적 성과였어요. 그래서 여러 가지 워크플로우를 통해서 앞으로 워크플로우 캠페인을 대체할 테니 그 캠페인들의 성과들로 타겟한 고객군이 결국 올바르게 성장하고 있느냐 이게 결국 CRM이 답해야 되는 질문이라고 생각을 했거든요. 그 측면에서 오디언스의 성장 추이가 시계열로 결국은 따라가지 않으면 우리가 성장하고 있다는 걸 보여주기 어렵겠다는 생각이었어요.

왜냐하면 말씀하신 것도 고민했던 게 이렇게 되면 사실 저는 비용 문제를 더 많이 걱정하긴 했거든요. 만약 오디언스를 100개 200개씩 깔아놓은 쇼핑몰이 사실은 모니터링도 하지 않으면서 하지만 우리가 내부 정책 때문에 매일매일 배치를 돌려가면서 이 비용을 쓰는 게 맞을까라는 고민을 오히려 했고 그런데 그럼에도 불구하고 일단 CRM에서 제가 풀고 싶었던 이 질문에 답을 하려면 저 시계열에서 따라갈 수 있는 어떤 성장 추이를 그려줘야 되는데 그 부분을 그려주기 위해서는 1배치 정도로 따라가야겠다

트래킹해야겠다라고 생각은 했어요 그럼 신규 지금 동적인 세그먼트 오디언스로 설정해놓은 오디언스에 신규 유입되고 이탈하는 건 하루에 한 번씩 맞아요 그렇게 생각했어요 중요한 지점이라서 잠깐 시간을 좀 썼고 혹시 계속 이 어젠다에 대해서 얘기하고 싶으시면 손을 꼭 들어주세요

제가 보고 있겠습니다 넘어갈게요 그리고 이거는 넘어가도 괜찮을까요? 개인정보 관련된 얘기였고요 그리고 두 번째 거 네 이거는 보셨겠지만 제 생각은 다음과 같았어요. CSB 업로드 핵심이 외부 플랫폼으로부터의 마이베이션이라는 거예요. 완전 동의를 하고요. 저도 그렇게 된다고 생각하는데 이쪽에 선결과제가 좀 있어야 될 것 같아요.

저는 선결과제에 대해서 잘 이해를 못한 상황이었어서 기존에 카페 입사에 멤버 아이디 값으로 저희가 동기화하는 게 가장 쉬운 방법이라고 생각해서 일단 PRD 내용을 그렇게 적었고 근데 동호님의 이야기를 들어보니 그쵸? 그러면 우리가 내부적으로 어떤 통합 모듈 정책이 있어야 될 것 같은데 그거에 대해서는 얘기를 한번 해보고 싶었다. 그럼 저 궁금한 게 처음에 CSP 온화드 기능 얘기하셨던 게 저는 특정 타격 고객을 지정하기 위해서라고 얘기를 했었는데

지금 어쨌든 대표님이 얘기하신 거는 외부 플랫폼으로부터 와이그레이션 했었을 때 임의적으로 하기 위해서 약간 목적이 좀 달라지는 것 같고 초기 목표가 뭐라고 했던 거고? 초기목표 지아님 말씀하신 거 맞는데 동훈님이 말씀하신 것도 전 어색하진 않다고 생각해요 왜냐하면 마케터 입장에서 생각을 해보면 대상 고객이 카페14에 있을 수도 있지만 쇼피파이에 있을 수도 있는 거잖아요 그러면 이네들을 어쨌든 우리가 CSV로 업로드를 해야 될 상황이 될 텐데

오디언스를 만들어야 될 테니까요 그때 우리는 멤버 아이디 값이라는 건 카페14랑 우리가 같이 공통을 쓰고 있는 거일 뿐 사실 쇼피파이나 아니면 또 다른 어떤 플랫폼이랑 공통 지금 그건 아니잖아요. 그래서 그거에 대해서 우리가 정리를 하자라고 전 이해를 했거든요. 그러면은 여전히 그 초기의 목표도 유효한 건가요? 저는 네 당연하죠. 그건 유효하다고 생각했어요. 그런 약간 마이그레이션 관련해서 고려하는 거는 페이지를 쳐서 가고

초기 목표에 대한 걸로 이제 호조개랑 멤버 아이디 맞춰보는 그 부분에 대해서는 페이스 원으로 해서 이번에 막 들어가는 건 어떤지 싶긴 해요. 네. 아마 저건 근데 저도 지금 다룰 수 있을까 생각을 했고요. 사실 개발자들이 답변해 줘야 되는 부분인 것 같습니다. 생각보다 난이도가 그렇게 높지 않다. 그래서 스페이지 1에서도 해볼 수 있을 것 같다고 하면 저야 당연히 환영이죠.

정책적인 게 정말 중요할 것 같아요. B1하고 어떻게 원래 할 것 같아요. 매칭이 안 되면 저희가 들고 있는 알파 아이디가 따로 있어야 하는 게 좋겠는데 매체 안되면 안된 것대로 다 보여줄거고 그 사람이 또 다른 플랜폼에 있는 아이디 혹은 전화번호랑 식결자로 전화번호랑 식결자를 줄 수가 없어가지고 그게 또 모자뿌치이구요. 사실 지금 개념도 없고 존재하지 않는 상황이라서

아, 답이 어려울까? 그 자체는 둘 다 있는 것 같긴 한데요.

둘 다 라는 게 그냥 리스트를 만든다 그 자체에요. 외부에서 올라오는 게 확실히 기본으로 되어 있는 것 같거든요. 얘네는 일단 플랫폼 종속이 딱히 없어요. 휴대파일이 없어도 쓸 수 있는 솔루션이라서. 그럼 대초에 고민이 되어야 되는 상황인 것 같고 뭔가 이제 다리를 나눠서 생각을 해주셔야 될 것 같고

아마 기획자들 입장에서는 막연하게 어려운 것이다 막 오만 생각할 테니까 그게 얼마나 어려운 건지 어떤 조건들이 필요한 건지 이것들에 대해서는 이야기를 해봤으면 좋겠다 근데 이거는 정말 사실 알파이브스의 방향성 중에 하나일 수도 있겠는데 푸쉬 입장에서는 CRM 입장에서는 되게 중요한 개념이거든요 이걸 이 선택을 하냐 안 하냐에 따라서 CRM이 더 확장되지 않은

뒤로에 있는 것이기 때문에 이쪽에서 고민을 더 해주셔야 하는 것 같다는 생각이 들고요. 그래서 제가 썼습니다. 설계를 할 때 멤버 아이디를 검증명단으로 일단 페이즈원에서 쓰더라도 나중에 확장성을 고려한다고 했을 때 뭔가 해볼 수 있는 노력들이 있을까요? 푸시 기준에서는 저게 되려면 통합권점에서 다 같이 합의하는 어떤 기준이 있어야 될 거니까

저희끼리로 정한다는 의미가 있을 거 같아요 하긴 그 기준을 모르는 상태에서 우리가 먼저 설계하는 게 큰 의미는 없겠네요 하지만 나중에 어쨌든 그 기준이라는 게 후행적으로 만들어질 텐데 만들어지고 나면 일단 저희가 처음에 설계했던 것들을 유연하게 변경은 가능해야 될 것 같긴 해요. 이건 너무 당연한 거고. 넘어가겠습니다. 그리고 혹시 놓친 게 있을까요?

체크하는 거 4번. 다음은 오디언스 수량 제안이고요. 이거 밑에 또 나와요. FAQ 나와서 그때 한번 다시 다룰게요. 은하 씨한테 하는 얘기예요. 99개월 어쨌든 제안할 거 다 하는 얘기고 그러면 워커플로우에서 생성할 때 터트려야 되는 거거든요. 그거 이미 UI 점프 준비가 돼 있어서 모델되지 않았어요. 왜 있죠? 이미 고려해서 만들었었어요.

오리언스 개수 최대 개수 최대 개수는 뭔지 모르지만 불러오는 종합 자체는 UI 상이 있어서 브레이즈도 스페이스 개념이 있는데 거기서 50개의 문화처럼 클라비오는 무제한, 그 다음에 블레이즈는 50개, 해클이 몇 개였죠? 해클은 몇 개였고 총 3가지로 내내는데 아예 무제한으로 풀어주거나 아니면 1000개 정도로 제한을 두거나 아니면 플랜별로 분기해서 플랜별로 이게 오디언스가 아마 생성하다 보면은 이게

계속 어 내가 계속 이 자산들을 관리하고 싶은 데 라는 니즈가 생길 거라서 근데 또 팀리뷰 할 때 혹시라도 요거에 대한 니즈가 아주 강렬하면은 여기서 진짜 플랜별로 등급을 나눌 수 있지 않을까 라는 얘기를 아주 러프하긴 했었죠 하지만 그 얘기는 아니니까 좀 넘어갈게요 다음은 구매여정 상태 및 고객 노출의 원칙이구요 지금 edges 상태값을 일단 가져오긴 했어요 이게 저한테 핵심 좌표계라고 제가 표현을 했는데 미구매에서 첫 구매, 첫 구매에서 재구매에서 고바먹어요 다들 잘 아시는 내용일테니까

그래서 이 부분 이따가 이제 디자인 무조건 봐야 될 것 같네요. 디자인 보면서 한 번 더 시나리오에 대해서 얘기해 보면 좋을 것 같고요. 아직 동호님 질문처럼 4 곱하기 N 해서 그 N이 세 가지가 기존의 에즈 이즈 형태로 가져가는 것도 옵션 1번이고요. 옵션 2번은 또 현진님이 생각하신 아이디어가 있어요. 그래서 현진님이 생각하신 아이디어로 가져갈지도 고민이고 여튼 포인트는 맞아요. 4 곱하기 N 개로 가는 게 좋을 것 같고 이게 아마 프리셋이 되겠죠.

그래서 이것보다 혹시 더 좋은 어떤 하이 옵션의 아이디어가 있으면 좀 더 받아보고 싶긴 했다. 예를 들어서 카페14 프로 같은 경우는 방문, 장바구니, 구매와 같은 행동 기준으로 3개의 핵심 가변 상태가를 또 나누거든요. 그래서 얘네처럼 하는 것도 방법일 수도 있고요. 이거는 이따가 디자인 부분 한 번 더 아이디어를 구하도록 하겠습니다 다음은 오디언스 관련된 내용이고요 이 부분 첫 번째 성과 측정한 부분을 워크플로우 성과랑 어떻게 구분할까요? 라는 내용이었고

두 번째도 있네요 그리고 정적인 리스트형이 오디언스가 아니라면 성과 집계를 어떻게 해야 될까요? 정적인 리스트 형태의 오디언스의 성과 집계에 대한 질문이었던 것 같고 반대로 리스트가 아니면 계속 걷기잖아요 네, 화면 한 번씩 바뀌고 아 그거요? 네, 맞아요. 그래서 저 밑에는 제가 잘못 이해를 해가지고 이건 빼고 위에 있는 걸로 제가 답변을 썼고

저는 소유권이라고 생각했는데 자산, 제가 자꾸 자산이라고 표현한 거는 결국 타겟 고객집단의 성장, 즉 오디언스의 지표를 저는 소유권이 오디언스 쪽에 있다. 그래서 예를 들어 모수, 사고파괴, 프리셋의 여정들, 그 다음에 전이율, 채널별 도달 가능성, 그 다음에 액션의 실행 여부랑 존재하는 그 무언가의 지표들이 저는 자산이라고 표현을 했고요. 두 번째가 마케팅 캠페인의 성과 지표, 워크플로우가 저는 소유한다고 생각했어요. 오디언스 화면에는 이 오디언스 참조 워크플로우 목록이랑 성과의 롤업, 간단한 표시 정도로만 생각을 했고

그게 디자인이 지금 반영되어 있는 상태이고요 그래서 산식이나 정보는 당연히 소유권이 워크플로우 쪽에 있기 때문에 전혀 관여하지 않고 오디언스는 그냥 무조건 불러온 다음에 롤업을 보여주기만 한다 정도로만 심플하게 생각을 했었습니다 그래서 그걸 억밀하게 구분해야 된다는 게 오디언스 독립지표는 무엇인가? 그러니까 오디언스만 소유해야 되는 지표가 무엇인가? 가 써있지는 않은 것 같습니다.

그거를 정해보시는 게 좋겠습니다. 저는 계속 가정이 되는 게 전체적으로 써있는 게 오디언스에서 마치 메시지로 보낸다. 혹은 트레이버가 발생한다. 그리고 또 지표도 수집한다. 이렇게 되어 있었어요. 지금 전체적으로. 그런데 그러면 안 된다. 라고 얘기를 전체적으로 했다고. 그러면 결과적으로 지표에 대한 부분은 오디언스에서 독립적으로 가져야 되는 창문은 무엇인지에 대한 목록을 작성해 주셔라.

사실 처음에는 제가 정신없이 썼다가 줄이고 줄여서 한 줄 남겨놓은 거긴 하거든요. 그러니까 구매 여정의 상태가 제일 중요한 오디언스 지표라고 생각하긴 했어요. 그래서 지금은 4단계 여기에 3개가 들어가든 4개가 들어가든 곱하기 4, 3이 되겠죠. 그럼 적어도 여기서 우리가 측정해야 되는 것들. 그러니까 이게 고반복 구매까지 가는 게 저는 이 자산이 건강하게 성장하고 있다고 일단 생각을 했고 단순히 모수가 커진다도 있겠지만

그래서 우리가 각 채널별로 우리가 타겟팅할 수 있는 그 모수의 숫자들 그다음에 전환율, 전이율 이런 것들 예를 들어서 클라비오 같은 거는 열람률 그다음에 실제로 수신율 같은 것도 체크를 하고요. 다른 데 카페 시사 같은 경우는 미구매에서 첫 구매로 갈 때 또 첫 구매에서 재구매 갈 때 이런 식으로 옮겨 갈 때마다의 뭔가 ARPU 같은 것들, 객단가들 이런 것들을 오디언스들의 보통의 핵심지표로 삼기는 하거든요. 여기서 크게 달라지지 않는 것을 일단 저는 생각하긴 했어요. 저는 조금 그 다음 그때 얘기했을 때

로아스나 구매자랑 같은 경우에는 오디언스에서 없어야 된다고 생각했어요. 그리고 이 미구매 작품의 무반복 구매 같은 경우에는 오디언스를 설정하기 위한 오디언스의 조건 정도만 생각했지 지표로 돼야 되는 건 아닌 것 같거든요. 그래서 약간 혼동이 있는 것 같아요. 왜냐면은 오디언스 설정 해놓고 이제 뭐 노드 연결 해봐줘 워크플로우의 총 전환은 꼭 구매 전환이 아닐 수도 있잖아요. 회원가입일 수도 있고 그렇잖아요.

그렇기 때문에 전환에 대한 구매 전환, 미구매 이런 여정에 대한 지표가 되는 게 맞나? 네 얘기해보면 좋을 것 같고요. 말씀하신 로아스 같은 경우도 이제 단일 마케팅 즉 워크플로우의 성과로서도 보여줄 수도 있고 근데 이제 오디언스라는 것은 누적 집계 성과인 거잖아요. 타겟 고객들한테 계속해서 여러가지 마케팅 캠페인들을 쓸 것이고 그렇다 보니까 평균치를 저는 낼 수는 있다고 생각하긴 했거든요. 평균적인 어떤 로아스라든지 평균적인 수신율 클릭률 같은 것들

그러니까 이 중에서는 이제 우선순위는 사실 잘 모르겠어요. 좀 더 오디언스에 가까운 평균치의 값들, 의미 있는 것들을 보여주는 것들. 근데 별로 의미가 없어. 이런 거는 사실 단일 캠페인이나 워크플로우의 성과로서 존재하는 게 더 나을 것 같아. 그러니까 그냥 미노출하자라는 결정도 저는 당연히 수용할 수 있다고 생각해요. 그러니까 미노출하다 이런 건 전 아닌가. 이제 오디언스 확보화 지표를 바라보는 페이지가 있을 거잖아요. 그 페이지에 이런 지표도 들어갈 수 있죠.

근데 이 지표들이 어디서 출발하냐, 어디서 집계하고 어디서 소유하고 있냐, 워크플로우에서 소유하고 있는 것들이 대부분인 것 같다. 말씀을 드리는 거고요. 그 부분이 좀 명확하게 안 돼 있는 것 같아서 그러니까 소용가 어디냐 이걸 명확하게 하자는 얘기를 드리는 겁니다. 그러니까 수신률이나 클릭률 같은 것도 다 쉽게 하고 있고요. 근데 다만 이런 거죠. 오디언스는 여러 워크플로우를 참조할 수 있잖아요.

그러면 그 워크플로우에서 수신률과 클릭률을 어떻게 계산할 것이냐는 남의 문제거든요. 그런 것들이 지금 워크플로우에서 얘기하는 수신률과 클릭률이랑은 조금 다를 수도 있거든요. 예를 들어서 워크플로우 안에 있는 클릭률을 보자면 예를 들어서 메시지에 대한 클릭률도 있을 거고 팝업에 대한 클릭률도 있을 거예요. 그걸 합산하는 기준이 저희가

이제 율 자체는 사실 이렇게 살았지는 않는데요. 지표 안에서는. 어쨌든 이걸 하려면 그 클릭들을 합산하고 그 다음에 사람 수로 혹은 행동 수로 해야 되겠죠. 행동 수로. 행동 수로 나눠야 되겠죠. 행동 수라는 게 팝업이 몇 번 노출됐냐 메시지가 몇 번 발송했느냐. 이게 부모가 될 거고 그래서 부모랑 분자 이렇게 나눴을 때 클릭 율이. 그런데 이게 워크플로우 하나에 대한 얘기인거에요. 워크플로우가 여러개가 있으니까 이게 다시 또 합산되서

저희도 프로젝트라는 ML이 있다고 말씀드렸었는데 워크플로우 여러개 합산한 프로젝트 ML을 봤을때 프로젝트에서는 합산을 어떻게 하려고 하냐 하면 얘네들 얘네들 이렇게 합산해가지고 또 나눠라 이렇게 세워놨어요. 그것처럼 이것도 지금 똑같이 하면 될 것 같긴 한데요. 설명드린 것처럼. 그런데 구성원 1인당 귀성 매출. 이런 것들은 워크플로우의 노드의 지표 안에 매출이 들어가 있을 거라고 보고요.

그 위에 다시 또 워크플로우 그다음에 프로젝트 이렇게 있을 텐데 이것도 오디언스잖아요. 그러니까 이걸 롤업하는 방식이 달라져야 보통은 좀 무드랑 워크플로우랑 다른 거라고 봅니다. 일단 궁금한 게 생겼는데요. 그러니까 워크플로우들의 집합인 프로젝트가 결국 소유하고 있는 모든 지표의 평균들은 여러 가지 워크플로우 캠페인들의 총 그거잖아요. 이걸 갖고 있는 거고 바라보는 게 프로젝트인 거죠. 사람이 아닌 거죠. 사실 자산이. 자산이 여러 개가 있을 수 있다고 생각하는데 저는 고객 집단이라는 자산을 봤을 때 고객 집단이 잘 성장하고 있는가였던 거고

프로젝트는 사실 시작과 끝이 있을 것 같고 해당 프로젝트는 굳이 뭔가 사람이란 자산이 아닐 수도 있으니까요. 그래서 다시 돌아가서 얘기해보면 저는 계속해서 그냥 이 CRM 도구가 풀어야 되는 문제는 마케터가 상정한 이 고객 집단이 잘 성장하고 있는가를 그냥 잘 보여주면 된다였고요. 그래서 지표는 이제 그걸 보여주는 어떤 증거가 될 것 같은데. 네, 다 틀리고 그런 얘기를 하는 건 전혀 아니고 그냥 저희 지표 체계에서 어떤 걸 참조할 것인가 어떤 계산을 할 것인가만큼은 사실을 하고

그거는 팀 멤버에서 산책이나 이런 것들을 정하시면 좋습니다. 그렇게 하시죠. 그래서 저기 댓글 빨간 표시 빨간 표시 기존에 대표님이 워크플로우 지표책에 해놓으신 게 이거 같이 참고하면 좋을 것 같다고 그냥 그쵸? 음 그래서 음 거기 위에 보시면 그 밑에 중간에

워크플로우 지표 세금 내려가 주시죠 이거 내려가 주시면 한 번 더 내려가 주시면 여기 지표 사전이라고 보세요 이거 넣었고 그 게임 이제 그거를 나열한 거고요 물론 이거 3CG나 이 얘기가 아직 안 된 거 같았어요 네 사실 리뷰가 반듯하긴 했는데

저 직교들을 따로 수집할 거다 이렇게 보시면 되겠습니다 저는 이게 내부적으로 어디서 집계를 할 것이냐의 문제인 것 같은데 그랬을 때 뭐 어쨌든 VIP 오디언스를 만들었을 때 그 사람들의 어떤 구매 전환율도 보고 싶을 수 있잖아. 그거는 여기서 수집한 지표 체계를 참조해서 화면에 어떻게 보여줄 것이냐 정도만 생각하면 될 것 같고

지금 저희가 생각해야 될 거네. 그래서 오디언스 쪽에서만 관리할 지표가 뭔데 약간 이거를 좀 정해야 될 것 같다는 생각이 들었고 그래서 저는 생각했을 때 뭐 vrp라고 하면은 어쨌든 시계열로 보여주신다고 했잖아요. 그랬을 때 진짜 신규로 들어온 게 이때 얼마나 많았고 이탈은 얼마나 많았고 이런 정도의 지표 정도만 일단은 생각나는 건가고 그렇게 좀 독립적으로 짙게 할 지표로 좀 생각해봐야 되죠. 다 얘기하시면 좋죠.

좋습니다. 저는 오히려 좋은 것 같아요. 오히려 지금 워크플로우 쪽에서 산식들이 있고 여기서 이제 우리가 불러와다가 필요한 것들만 막간스럽게 화면에 표시하면 되는 거잖아요. 저는 지아님이 그때 팀 리뷰했던 것 같으면 생각이 나는데 그때 우리가 시계열에 대한 중요성, 추이로 이 집단의 모수가 성장하고 봐야 된다. 특히나 우리가 핵심자 표기로 뒀던 구매 여정 4단계는 정말 중요하다. 이 정도까지가 저희가 그때 얘기했던 것 같고 나머지는 사실은 저한테는 약간 서브이긴 해요.

여기 지표명으로 제가 열심히 달아놓긴 했지만 이런 것들도 다 세팅인 워크플로우 쪽에서 갖고 있는 걸 가지고 조합해가지고 뿌리는 거는 사실 어렵진 않을 것 같긴 하다. 워크플로우 거랑 몇 가지가 있어요? 제가 지금 말한 거는 로아스 수신율 클릭률 같은 것들이요. 이제 실제로 오디언스에서의 평균 수신율, 평균 클릭률 같은 걸 보여주고 싶다고 하면 그때 롤업 회사에 보여줄 수 있는 거잖아요. 워크플로우가 그걸 보여주긴 할 건데요. 그거를 담당하는 거는 메시지 푸쉬가 할 거고요.

워크플로우가 예를 들어서 지금 오디언스에 대한 저게 나오지 않아요, 통계가. 그러면 정해진 거 아까 지하님 말씀하신 것처럼 오디언스 자체가 보여주어야 할 통계값이 있을 거잖아요. 워크플로우가 오디언스 관련된 노드를 쓰게 되면 거부해야 지표가 또 있을 거거든요. 그건 이제 워크플로우가 가져다 쓰겠죠. 워크플로우는 배상한 데이터를 갖고 있지는 않을 거예요. 네. 예를 들어서 모수 같은 거는 계속 트래킹하나요? 워크플로우는. 안 하겠죠.

저는 이제 그런 것들은 반대로 가져다 쓰실 것 같아요. 이건 지금 근데 기술적인 얘기인 것 같고 개념상에서는 지금 어플로 다 갖고 있다고 이해하시면 되는데 그냥 지금 메시지 발송 추체는 PC 쪽 서버에 들어가 있는 게 제외적이 된다고 얘기를 하는 거죠. 그렇죠? 이건 다 그런 거잖아요. 오디언스도 모르고. 근데 지금 얘가 오디언스 안에서만 지표를 따로 수집한다 이런 게 아니라는..

그렇죠. 그거는 예. 저도 동의를 했고. 오디언스에서 지표 따로 수집할 게 없어요? 모수 정도는 트래킹을 해야 될 것 같아요. 시계열로 해서 가는 거는. 규모도 따로 있는 것들이.. 보통은 워트플로우에 있는 개념들은 아니라서 저장하실 거면 저장하는 게 맞는 것 같고요. 이거는 중요할 것 같아요. 노드 지표가 다시 한번 가주시면 여기도 사실 맨 위에 가거든요. 네. 노드에 특정되어 있지 않은 워트플로우의 시작 수, 대기 수, 완료 수 이런 것들은 워트플로우가 저장을 해야 될 거란 말이에요.

네. 저런 거 보자면. 그래서 저거랑 비슷하게 오디언스 자체도 가질 수 있는 지표도 있을 거예요. 그건 알겠고 그러면 그게 무엇이냐고 정해보시라는 말씀을 드립니다. 좋습니다. 다들 이해하신 것 같으니까 이 부분은 저희가 오디언스에서 어떤 지표를 핵심으로 트래킹하겠습니다. 이게 답변하면 되는 것 같아요. - 죄송한데 수신률이랑 클릭률 같은 거 있잖아요. 제가 비율 지표는 부족으로 뺐거든요. 그냥 프론트에서만 보여줄 수도 있고 하다 보니까

지금 지표가 너무 많아서 최소화 시키려고 비율 자체는 저장 자체는 안 하려고 했거든요. - 그래요? - 근데 모르겠어요. 이제 나중에 필요성이 생기면 할 수도 있을 텐데 그게 왜 스냅챠트를 떠야 된다 하면 뜰 수는 있을 거예요 넣었던 이유는 클라비오 걸 봤는데 좋아 보여 있길래 그냥 가져오고 있긴 했습니다 좋아요 이거 중요한 얘기라서 좀 약간 얘기를 좀 했고요

혹시 놓친 게 있는지 잠깐 살펴볼게요 그 맞아요. 매출 기준은 따로 정해서 알려주신다고 해서 그냥 그때 한 번 더 검토하면 될 것 같아요. 위에 있는 내용 그쵸? 넘어갈게요. 그리고 위에 있는 것도 같은 얘기고 지금 잠깐 중간으로 점프를 한 것 같아서 위로 올라올게요. 사전 경고 팝업 예 이거 동의 주셨네요. 스냅샷을 찍는 걸 생각했기 때문에 액티브랑 인액티브 의미가 있을 것 같고요.

그렇습니다. 그래서 지금 계속 얘기가 나오고 있는 게 그거죠. 페이즈 1을 우리가 스펙을 상정을 할 때 오디언스랑 저는 CRM 개발 위주로 생각한 게 맞고 근데 이것보다 워크플로우를 먼저 선결해야 되는 걸로 생각하면 저희 지금 현재 스펙을 몇 개 바꿔야 될 것 같거든요. 근데 오히려 스펙이 줄어들겠죠.

그래도 스냅샷도 마찬가지인 것 같거든요. 지표랑 다르게 지표나가. 영향을 주겠죠. 추이를 봐야 되니까. 이게 이렇게 돼 있다고 해도 스냅샷을 뜰 지표들은 또 무언가를 구분해야 되지 않을까요? 스냅샷을 뜰 지표를 구분한다고. 지표를. 모수 말고요? 규모랑 성장도달 이런 거 말고요? 네, 뭐 아닙니다. 지표.

지표 사정을 저희처럼 하나 만들고 두 개 테이블을 엮어가지고 여기서 가져온다, 만다 이런 얘기를 이제 기표에서 하면 되니까 음 지표 트래바를 하면 안 되죠 그러니까 지표가 있고 데이터 확보 여부가 있고 오른쪽에는 산식이 있고 노출 확보될 부분 이거는 지금 동훈님이 세팅하시고

그 다음에 누가 팔로업을 하고 있나요 동훈님이? 네, 앞에 있는 지표만 보시면 돼요. 뒤에 있는 거는 지표 텍스트 그러면 이 부분 다시 돌아가서 오디언스의 지표 부분은 팀에서 같이 정한 다음에 자연스럽게 동훈님한테 공유가 될 것 같거든요. 그러면 동일한 노드 지표 사전에 올린다 이런 거는 그냥 동우님한테 맡겨도 될 것 같고요.

넘어갈게요. 사전 경고 팝업도 끝났고 다 넘어갈게요. 이 부분 넘어가고. 맞죠? 온 사이트랑 메시지 캠페인 성과 분리 원칙. 이거는 뒤에도 계속 나오긴 합니다. 이거 뒤에 있는 거 먼저 볼게요 FAQ에 동훈님이 같은 질문을 좀 남겨 놓으셨는데요 어디였지?

여기 있죠 온캠이랑 맥캠이 현재 세그먼트 기준 유저의 식별 기준이 다르대요 그래서 애초에 현재도 온캠 정보를 오디언스로 표현하는 것에 문제가 있다 엣지에드는 이제 알겠고 앞으로 어떻게 할까 옵션을 주셨는데 저는 이 중에서 2번 옵션이 좀 어떻게 표현하는지 모르겠는데 가능하지 않을까 라고 생각하긴 했어요

왜냐면 1번 옵션으로 가게 되면은 오디언스의 이벤트별로 그러니까 온사이트 이벤트별로 오디언스들이 막 생성이 될 거고 이런 것들을 현재 제가 쓴 PRD대로라면은 매일매일 배치 돌면서 똑같이 성장률 관리를 해줘야 될 텐데 그 정도일까 라는 생각이 들었어요 온사이트이기 때문에 차라리 2번처럼 이번 제가 제대로 이해한 게 맞다면 핵심 구매 여정들이 존재할 거고 이게 사실상 프리셋이니까 그 안에서는 온사이트 캠페인을 추가로 좀 더 보여줘도 되지 않을까 정도였다. 만약에 1번, 2번 다 별로면

그냥 온사이트 캠페인은 이번 페이지 1에서는 스펙에서 제외한다고 할 수 있는 결정이라고 생각합니다. 이 부분은 개발자분들이나 다른 분들 의견 들어보고 싶었어요. 어떻게 생각하시는지. 궁금했던 게 그 온사이트 캠페인 데이퍼 중에 어쨌든 노출 횟수는 페이지 1 이런 거 저장을 하잖아요. 그렇죠. 네. 저장은 신하네요. 그게 어떤 지표들을 저장하냐고 하면 또 찾아봐야 되죠.

그러면.. 저장을 따로 하는 건 저 서버에요. 네. 저는 그래서.. 그냥 일단 저 문제가 태평 문제이긴 한데 일단 저희가 통합을 안 할.. 지금 안 한다. 안 한다. 그러니까 따로 유지하는 걸 여전히 인정할 거잖아요.

로컬스토리즈에 저장된 거랑 그냥 그걸 개별 합산해버리는 걸로 해야 될 것 같아요. 개별 합산이니까 다 합산해버리는 거죠. 다 다른 사람으로만. 그러니까 로컬스토리즈의 기준. 예를 들어서 저는 이제 도달수라는 걸 노출수랑 다르다도 이해하시죠 다들? 뭔지 알죠? 도달수는 사람 숫자고 노출수는 횟수잖아요. 근데 도달수에 대한 기준을

같은 사람일지라도 실제론 같은 사람일지라도 로컬스토리즈 기준의 개수의 사람의 수란 그냥 cdp에서 저장된 수자랑 합쳐서 보여주잖아요. 김동호 김민우가 김동호 김동호가 있으면 온셋트 파고 본 사람은 김동호 메시지 받은 사람은 김동호가 있겠습니까? 두 명으로 보면서. 분리해서 트래킹하자는 거잖아요. 온 사이트랑 메시지 캠페인이요. 이게 그런 문제야기보다는

워커플로우까지 넘어가면 워커플로우에서 식별 기준을 저희가 처음에 노드 유형을 회원이랑 상품 두 개로 크게 나눴었잖아요. 기억하시죠? 처음에 노드가 들어갈 때 회원 기준으로 들어가는 상품 기준으로 들어가는 것 처럼 회원 자체를 회원냐 비회원이냐로도 나눌 수 있어야 되지 않나 생각이 들었거든요. 그러면은 이게 그러니까 비회원도 커버할 수 있는 조건들이나 이런 것들이 있고

이벤트들이나 회원만 포함되는 이벤트들이 있고 그거에 따라서 좀 달라지지 않나요? 예를 들면 audience 설정에 1번 같은 경우는 이런 거죠. 특정 페이지를 3에 조회한 부적을 audience 설정을 할 수 있다고 하면 이건 사실 회원이냐 비회원이냐 둘 다 포함이 되는 건데

그 중에서 우리가 액션 노드로 메시지를 보내겠다고 하면 메시지는 회원만 보낼 수 있잖아요. 그러면 그 이후에 노드에는 노드에 들어갈 때는 회원 비회원 둘 다 들어갈 때는 메세지 노드에서 실제로 나올 때는 회원만 나오게 해서 BEO는 사라지고 그런 느낌으로 워크플로우 입장에서 그렇게 생각을 했었고 그런 관점에서 어쨌든 오디언스를 워크플로우가 사용해야 하는 입장에서 오디언스도 회원과 BEO는 나눠서

구분을 하면 되지 않나? 그냥 개인적으로는 그렇게 생각을 한 번 했었어요. 와 근데 어떻게 가능할까요 그게? 어떻게 가능? 가능은 하죠. 어차피 이벤트는 다 찍어 놓으니까 그러니까 뭐 예를 들어서 실제로 3회 반복해서 조회한 회원이라고 하면 조금 부자연스럽고 유저라고 하면은 그 유저가 쭈루룩 있을텐데 그 중에서 회원인 사람들이 있을 거고 비회원으로 구성된 사람들이 있을 거고

그걸 가장 궁금해서 그런데 그걸 알려면은 회원의 어떤 멤버 아이디 값을 로그인하기 전인데 어떻게 알 수가 있나요? 그거를 처음에는 비지터 아이디라고 해서 비지터라는 시킬 기준으로 로그인 브라우저 기준으로 하는데 만약에 로그인을 하면 그 비지터 아이디랑 멤버 아이디를 맵핑을 해야 됩니다 예를 들어 브라우저를 교체하거나 교체하면 또 다른 유연이 되겠지만 그렇네요

완벽하진 않지만 그래서 얼추 알 수 있다 정도 그리고 다른 데서도 그렇게 하고 있는 걸로 좋습니다. 저번 날이네. 그래서 이거는 메시지 캠페인이나 온사이트 캠페인 어떻게 오디언스에서 관리할 거냐 이 곡보다도 워크플로우에서도 이거를 어떻게 다룬 거냐도 같이 얘기가 같이 들어가야지 판단기준이 될 것 같아서

좋습니다 만약에 지금 결정하기 어렵다고 하면 세 번째 옵션처럼 종료를 말씀해주시면 일단은 제외하고 시작하는 것도 나쁘지 않을까 업플로우에 할인기념을 넣으면 업셀에서는 비회원을 당연하게 쓰고 있는 개념이라서 전맥이 충돌이 생길 거거든요. 그래서 화전의 검은토로 하는 게 좋을 수도 있어요. 현재 가능한지 오디언스로 계속 살 거라는 건데 업셀은 비회원을 당연히 쓰고 있어가지고

작업을 하게 되면 지아님이 하셔야 되니까 방금 동훈님이 말씀하신 아이디어 있잖아요. 방문자 아이디 값을 따로 트래킹해서 브라우저 기반이지만 이걸로 이제 비회원임을 우리가 식별할 수 있다 이거는 난이도나 이런 것들이 막 그렇게 페이지 1에서 다루기에 어려운지 쉬운지 이런 게 좀 궁금해요. 지금도 하고. 지금도 가능하고. 지금도 온 사이트의 아인 자체는. 그러면 안 할 이유가 없겠네요. 네. 네. 그러면 해당 PRD에 비회원 값에 대한 스펙이 들어가는 게 좋겠네요. 지금 얘기해보니까.

좋아요. 오디언스부터 오디언스, prd부터 비회원 식별에 대한 기능 스펙을 넣는다. 결정. 이게 좀 저는 잘 이해가 안 가는게 아까 그 워크플로우에 비회원을 구분하는 것도 같이 고민해야 된다는 그 이유가 문제에 대해서는 이제 얘기 끝나고 종호 씨랑 따로 얘기해요.

아 알겠습니다 네 좋습니다 좋아요 다시 위로 올라갈게요 지금 시간이 12시 3분인데요 거의 다 끝나가거든요 최선을 다해서 빨리빨리 해볼게요 디자인은 제일 마지막에 보는 걸로 하고 지금 다루지 않았던 거 여기까지 한 거고 그렇죠? 보자 한 거죠 Q. 오리언스 관련해서 질문을 한 게 있는데요. Q. 좋아요. Q. 어제 맞던 사람을 1회 배치 스냅샷으로 한다 했는데

Q. 숫자를 아는 건 알겠는데 Q. 과거에 누구였는지 명단을 알 수 있는 걸까요? Q. 왜냐하면 오리언스 제 워크플로우에 Q. 현재 시점으로는 맞았는데 Q. 과거에 커피를 추가하는 프리뷰 기능들이 들어갈 예정인데 Q. 이것도 오리언스랑 같이 관리되어야 되는 걸까? Q. 갑자기 물음표가 생겨서 Q. 질문하게 됐어요. - 네. 3일 전에 받았던 사람 그 어떤 트리거 그 설정은 오디언스 생성을 뭐에 대한 뭐는 했는데 전에 받았던 사람을 추가하고 싶을 때는 어떻게 할 것인지 궁금했어요.

그게 아니고 현재 시점에서 3일 전에 클릭했던 사람을 평가하고 있죠. 근데 이제 지금 숫자로는 기록한다고 되어 있는데 명단을 아냐 오디언스 측에서 아냐고 궁금해가지고 누구누구의 인식을. 당시에 스냅샷으로 모수를 알고 있으면 그 모든 사람 관련 없는 거예요? 관리할 필요 없는 거예요? 그러니까 제 생각에는 트리거에 지금 모수가 만들어진 당시에 지금 영향을 그 조건을 만족하는 사람들의 리스트를 확인하면 되는 거잖아요?

네 근데 그 과거 프로필이라는 걸 조사해보니까 그 시점에 맞지 않은 사람을 추가하는 개념이에요 플라비오가 지금 그렇게 되어 있어요 추가를 한다고? 네 예를 들면 어떤 개념이냐면 네. 그럼 추가된 사람하고 이탈한 사람은 알 수 있을 거예요. 이전에 임조건 충족했던 사람을 소급해서 넣어주는 기준이에요. 그 과거 프로필 추가가. 전에 워크플레이션을 만드신 장소로부터 실시간으로 대상으로 갔다가 진작에 들어왔으면 좋았을 때 사람들을 나중에 추가하는 게 되는 거거든요. 근데 그냥 사람 이름을 추가해요?

사람 이름을 추가하고 그렇게 프로필로 되어 있어요. 그 명단을 오디언스 쪽에서 관리를 하게 되면 그 명단을 워크프로에서 갖고 있는 게 아니잖아요. 아 예 그러니까 그 오디언스에 정확히 오디언스에 조금 만족하는 100명이라고 하면 100명에 대한 명단을 관리할지 안 할지는 아직 뭐 설계를 한 건 아니니까 모르겠지만 적어도 요구사항적으로 100명이 나중에 스냅샷을 돌리든 사람이 수동으로 업데이트를 하든 아니면 말씀 주신 것처럼 프로필을 몇 개를 추가하든 해서

만약 110명이 됐어요 아니면 90명이 됐어요 그때 추가된 사람이 있고 이탈한 사람이 있을 거잖아요 그 기록은 어쨌든 가지고 있어야 돼요 있다는 거죠? 기록은 다 있어야 돼요? 네, 변화에 대한 기록은 누가 언제 추가됐고 누가 언제 이탈했고에 대한 정보는 무조건 있어야 돼요 그 실제 명단을 실시간으로 관리하나 안 하냐는 우리 선택사항이지만 요구사항적으로 봤을 때 그 변경사항에 대한 기록은 무조건 우리가 알고 있어야 되는 것 같아요. 로그는 기록한가? 이거는데 그거를 실제 활용할 수 있냐는 다른 문제?

어 충분히 할 수 있을 거예요. 왜냐하면 그게 있어야지 저희가 오디언스 추가 됐을 때 그거를 트리거로 받아서 워커플로가 동작할 거기 때문에 네 답변까지 잘 된 것 같고요 사실 디자인적으로는 모수 숫자에 대한 이탈과 증감률만 표시를 해놨고 당연히 이제 현재 버전에서는 현재 스냅샷으로만 명단을 보여주거든요 동훈이 말씀처럼 이게 스펙을 우리가 여기로 가져간다고 하면 당연히 모수를 찍고 있기 때문에

명단 자체도 순회수사 남기는 것도 가능할 거라고 생각을 하고요. 이거는 넘어가도 될 것 같아요. 이거는 넘어가는 이유가 아까 지표 관련된 얘기라서 아까 이건 결정이 됐죠. 그래서 팀에서 오디언스 팀에서 핵심 지표들을 세팅해 가지고 여기 있는 산식이랑 맞춰서 리스트로 관리를 해서 서로 왔다 갔다 하겠다. 그리고 오디언스 연동 및 발송 안전 정책 5번 넘어갈게요. 여기서의 첫 번째는 뭐냐면요. UI랑 사람이랑 결국 에이전트가 동일한 오디언스 평가 인터페이스를 공유하게 될 텐데

이때 뭔가 생성의 출처라든지 작성의 주체 같은 것들을 어떻게 적재하지 이런 내용이었고 이게 이제 동우님한테 아마 하시는 질문인 것 같아요. 이것도 에이전트한테 도구를 지어주려면 오디언스를 만드는 것도 통합 모듈에 올려야 될 것 같네요. 혹시 뭐 더 몇 명이 있을까요? 저 스펙에 포함한다는 거잖아요. 네 맞아요. 그럼 뭐 일단 저기다가 모듈로 올리고 그거를 우리가 코어랑 얘기를 해야 될 거에요.

에이전트가 자동으로 이걸 만들어주길 바라는 거잖아요. 맞아요. 네. 아, 네. 왜냐하면은 여기까지 설계를 하는 게 맞아요. 화면 레벨에서는 우리가 에이전트 이런 표현 안 해서 그런 거잖아요. 그렇죠? 지금 하시려는 얘기가. 저는 뺐다고 생각했고 그래서 그 개념 자체를 프리셋 제품에서 기본적으로 조건을 맞춰서 제공하는 기본적인 프리셋 개념과 직접 사람이 생성하는 커스텀 개념으로 생각하게 했습니다.

사람, 에이전트 이라는 그 추후에 페이지 2가 됐든, 세면에는 추후에 -그런데 뭐 지금 초기 설계를 할 때는 여기까지 돼야 되기 때문에 워크플로우 우리 상정하고 EPLT 쓴 거잖아요. 당연히 있어야 되는 문장인 건 맞고요. 이거는 넘어갈게요. 당연히 통합물들 올라가야 됩니다. -그런데 에이전트가 워크플로우 만들면 어차피 거기에 오디언스 조건이 있고 그거 하면 만들어질 거거든요. 그러니까 작성 주체 부분 당연히 돼요. 맞아요. 맞아요. 그거 작성자를 누구로 할 거냐는 사람이냐 아니면 에이전트에 있는 태그나. 네 맞아요. 동일하게 생각하고 있었어요.

그리고 평가 시간에 대한 정의는 이건 넘어가도 될 것 같아요. 개발적인 부분이었는데 굳이 없어도 되는 문장일 수 있습니다. 그런데 취지는 뭐냐면 발송 요청 API 3초 응답 SLA 때문에 대상자 재개설까지 3초 안에 끝나야 된다라는 DOD가 너무 가혹하기 때문에 그런 내용은 아니었습니다라는 추가하게 멘트였어요. 그리고 5.2 실행 단위 실패 상태 및 객체 구조 분리 이거는 민우님까지 포함해서 얘기가 돼야 되는 거 같네요

어떻게 생각하시는 걸까요? 이건 근데 일단 종우님의 친리뷰가 된 거잖아요? 그러면 저 말이 전혀 발송 상태까지 관리하겠다 얘기는? 맞아요. 처음에는 PRD를 쓸 때는 일단은 다 고려한 상태에서 리뷰 받아가면서 스펙을 조정해 보려고 했거든요. 저는 오히려 디스패치 실행 영역에 있어서는 오디언스 소유가 아니어도 당연히 상관없다고 생각합니다.

그 의념은 안 되는 거죠? 안 된다는 얘기일 거예요. 지금 자기들은 다.. 발송 관리를 어떻게 할 거냐에 따라 다르죠? 워커플로우에 통합을 시킬 건지 아니면 푸신과 오디언스 관리하듯이 오디언스 발송 자체를 따로 관리하게 할 건지 근데 지금 어떻게 돼 있는데요? 지금 메시지.. 지금 읽었어요. 이게 뭐예요? 그니까 고객 관리에서 메시지를 보낼 수 있잖아요 그것처럼 오디언스에서 바로 발송하고

그 발송 결과나 이런 거 관리를 역사하겠다는 그렇게 하겠다는 거예요? 네 CRM만 생각을 했었어요 기존의 엣지에이징에서도 되는 부분이기 때문에 굳이 소유권을 워크플로우로 이전시킨다까지는 고려를 안 하긴 했습니다 워크플로우만 할 때 아니라 메시지 발송하는 쪽이 담당하겠죠? 그럼 이거는 소유권이 그냥 워크플로우에 있는 게 맞는 거네요? 워크플로우요? 아 죄송해요. 오디언스. 메세지 CRM이라고 표현할게요. 제가 말을 많이 하니까 말이 꼬이네요.

근데 여기 보면 데이터 구조 명세가 이렇게 쌓여있으니까 여기서 다 써놓은 걸 만들어놨을 텐데 여기서 설계하고 볼 거가 아닐 거 같나? 좋아요. 그걸 UX에서 어떻게 표현하고 이런 것까지만 표현하는 것이 있고 기존대로 CRM이라고 할게요. CRM에서 다루면 돼요. 그리고 지금 너무 다 메시지에만 생각을 하고 계시는 것 같은데 말씀 계속 제가 위에서 댓글을 계속 한 것처럼

캠페인 액션들이 6가지가 있다고 상품추천은 나중에 고려하더라도 적어도 5가지가 고려되어야 한다는 얘기를 좀 드리고 싶습니다. 예를 들어서 이런 거잖아요. 지금 제 이야기를 보고서 생각이 드는 것은 마치 오디언스 목록이 메시지 발송만을 위한 이거 지금 메시지 발송 대기 중입니다. 이렇게만 되어 있을 것 같은 그런 느낌이 들어요. 맞아요. 맞아요. 근데 워크플로우 안에는 여러 오디언스를 참여할 수 있는

메시지 뿐만 아니라 쿠폰 할인이나 이런 거 다 들어갔다는 거잖아요. 그렇게 할거면 그냥 그 오디언스 기준으로 워크플로우를 넘겨버리는게 낫지 않아요? 오디언스에서 발송을 권장하는게 아니라 그냥 이 오디언스 기준으로 발송을 하든 팝업을 띄러든 할 수 있는데 워크플로우 쪽으로 넘기는게 낫지 않아요? 대표님 기준이랑 발송을 무슨 말이에요?

워크플로우 오디언스에서 발송 뿐만 아니라 다른 옵션들도 있는데 지금 발송만 하는 것처럼 기획이 됐다는 거잖아요 그게 싫으면 그냥 오디언스 오디언스만 관리하고 이런 실행 같은 건 아예 워크플로저 넘겨버리면 되지 않냐는 거죠. 그 말이고, 근데 다만 오디언스 몸무게에서도 저는 저게 그런 거라고 생각해요. 상태값들을 표기하고 싶다 이런 얘기인 것 같고 그 상태값이라는 게 메시지 발송에 대한 상태값을 오디언스 몸무게에서 표시하고 싶다고 그럴 수 있죠.

그것까지 제가 뭐라고 하는 건 아니고 근데 다만 그 상태값들에 대한 정의하든지 이런 것들을 여기서 하는 게 오히려 당연히 여기서 정의하고 있는 건데 그래서 답 자체는 여기서 하시고 UX적인 거 보면 하시면 하나만 정정하자면 오디언스에서 상태값은 그냥 액티브 상태냐 아니면 인액티브 상태냐 두 개만 보고요. 그 하위에 있는 해당 오디언스별로 메시지부터는 전 다 워크플로우 쪽이라고 생각하긴 했어요. 거기서 상태를 보여주지 않았습니다 평가적으로 캠페인 실행, 스케줄드, 스피어링, 그런 건 뭐예요?

해당 오디언스를 집계할 때를 상정하고 생각했어요 그러니까 이게 무수를 집계를 할 때 디스패치 익스큐션이라고 돼 있고 디스패치 아이디랑 이런 게 있잖아요 디스패치 아이디는 진짜로 있는 개념인가요? 있는 사이에서 그냥 써진 거죠? 그래서 실제로 저는 지금 워크플로우에 쓰고 있고 새로 생긴 거에 지금 이거는 그냥 AI로 쓰신 거 같아요 그러면은 그냥 발송 자체는 워크플로우가 된다는 거죠?

아까는 저희 작성하실 때 실행을 저는 푸시 쪽에서 오디언스에서 발송하는 거는 푸시가 관리한다고 이해했어요 그래서 말씀드렸어요 그리고 제가 계속 이건 분리하고 실행을 하는 거 워크플로우 영역에다가 그렇게 하시죠. 고객 관리 또 그렇게 되어 있어요. 고객 관리에서 캠페인도 바로 발송할 수 있으니까 동물님이 얘기해서 오디언스에서 캠페인 바로 발송하는 걸 얘기해 주시는 거 같아요. 가능하죠. 그거는 가능하겠죠.

그거지 않아? 근데 여기서는 또 다른 일이 있는 거 같아요. 그러니까 바로 가능하면 그 워크플로우 발송으로 관리 안 한다는 거죠 대표님은? 오디언스에서 이 오디언스한테 메시지를 발송한다고 했어요. 그럼 그 워크플로우의 오디언스에서 메시지 발송으로 갈까요? 아니면 그냥 푸시 안에서 오디언스에서 발송한 결과로 관리될까요? 아 저기에서 만들어져도 저는 워크플로우의 센스에 생겨난다는 거 생각해요.

그걸 아까 여쭤봤던 거고 제가 이해한 건 아까는 워크플로우로 관리 안 하고 자체적으로 관리한다 라고 여기다 댓글을 적어주신 것 같아서 오디언스 메시지 발송에 대한 부분은 기준대로 CRM에서 다 본다 라고 적어주셔서 그래서 그게 맞는 느낌이었어요. 지금 이거 보면 오디언스잖아요. 여기 오디언스에서 캠페인 바로 발송이 가능하니까 현재 에디지 상태처럼 메시지 발송에 대한 거는 그냥 오디언스에서 진행되는 거예요. 그럼 이걸 눌렀어요. 그러면 실제로 이 오디언스에 이 메시지 발송이라는 기록이 워크플로우에서 관리가 되냐.

워크플로우에서 생성이 돼서 아니면 그냥 그 자체적으로 여기서 관리가 되냐. 워크플로우에서 기록이 되는 거고 말씀하신 건 UX적인 거 같아요. 버튼이 여기 있다. 여기서 생성할 수 있다. 이런 얘기로 이해하시면 되겠습니다. 그렇죠? 감사합니다. 사실 생각 안 했는데 맞는 것 같아요. 메시지 발송 클릭하면 메시지에 대한 모든 것들은 사실 다 캠페인으로 봐야 되는 게 맞고 그러면 워크플로우에서 관리하겠다가 대원칙이잖아요. 그냥 대원칙대로 가야겠죠.

쉽게 생각하면 실행의 영역은 뭐 다 필요하는 거 없죠. 워크플로우 자체도 다 소유하는 건 아니고 각자 액션 모드들이 따로 소유하고 있는 것들을 모아서 보여주는 것. 얘는 워크플로우가 아니라 오디언스라는 독립적인 개체로 매리가 되는 건데 어쨌든 고객 입장에서는 오디언스 목록을 들어와서 뭔가를 하고 싶을 거고, 뭔가를 확인하고 싶은 거고 이런 게 있으니까 그 기준에서 작성을 해주시면 더 좋을 것 같아요 그러게요 이게 진입점이 어쨌든 채널이 생기긴 하네요

메시지 발송까지 워크플로에서 시작할 수 있지만 오디언스 관리 체계에서도 시작할 수 있는 거니까요 이미 아까 저 데모 보고 들어왔거든요 데모 만드신 거 네 지금 똑같긴 1회성이랑 뭐 자동화 캠페인 두 개 다는 거 봤는데 그것조차도 제가 얘기해 드리는 거예요 그러니까 다른 액션 노드들이 있기 때문에 두 가지 액션만 할 수 있는 건 아니라고 아니에요 다른 분들도 애써는 할 수 있습니다. 계속 얘기해야 할 것 같은데 어쨌든 지금 확실한 건 메시지만 생각하지 않을까

그럼요 여기서 시점 다시 한번 얘기해보자면 저희가 오디언스 더하기 CRM이 훨씬 더 빨리 개발이 될 거잖아요 저희는 사실 다음 사이클에서 이걸 지금 태울 준비를 하고 있거든요 그렇게 되면은 일단은 메시지만 생각하고 저희는 개발을 해야 되기 때문에 이 PRD는 일단 그렇게 써야 할 것 같기는 해요 워크플로우랑 같이 들어가면 되지 않아요? - 어떻게 들어가지? - 워크플로우도 어차피 9월 내에 출시가 없는데

- 그래요? - 어 이 오디언스 자체가 워크플로우 때문에 작업한 거 아니었어요? 그렇기도 하죠. 근데 근데 그걸 기본에서 메시지만 생각하겠다고 했을 때 UX나 뭐 이런 것도 다시 만드실 거 같아요. 그러니까 저는 그게 걱정이 돼서 무려하라. 예. 저희. 다시 또 만들어야 될 거에요. 저희가 배포 내리는 거 같아요. 그럴 이유가 없지 않냐. 그래서 지금 이게 저는 이거를 한번 보고 오늘 이걸로 막 다 정하는데 이렇게 안 될 거라고 생각할까?

일단 이제 뭐 개발적으로는 잘 모르겠습니다만은 이제 UX적으로는 확실히 저희가 무슨 노드 있는지 아시나요? 모르죠. 왜 몰라요? 공유 드렸잖아요. 결국 이렇게 되었단 말이에요. 그래서 저거를 제가 아 이런 부분 아마 여기서 쇼팟으로 만들어 주시려고 하시는 것 같은데 그러면 이런 기능들도 더 추가하셔야 됩니다. 이런 얘기를 계속 드려야 할 것 같거든요. 그 과정이라고 보시면 될 것 같습니다.

알겠습니다. 정리하면 메시지 뿐만 아니라 쿠폰 할인 등등 여러 가지 시나리오를 워크플로에서 새로 준비를 하고 있고 그게 9월에 개발 예정이다. 이게 아주 먼 갭이 있는 일정이 아니라 거의 붙어있거나 거의 동시에 이루어지기 때문에 지금 기획 설계할 때부터 같이 고민해서 적용해야 된다고 이해했고요. 이 미팅 끝나고 나면 내일이든 이번 주에 한 번 더 말씀하신 액션 노드들에 대해서 얘기할 수 있는 시간이 있으면 좋겠네요. 네 그리고 추가로 어차피 부서 없이 진행되는데 오디언스 빌더에 대해서

디펜던치가 저희가 이쪽에서 잡히는 게 있거든요. 오디언스 빌더를 저희 쪽에서 만들려고 했는데 사실 그 오디언스 빌더를 오디언스 만드는 쪽에서 만들려고 했다고 생각했어요. 당연히 그게 맞는 것 같거든요. 동전시 빌더에 대해서 일단 인수인계를 드리고 여기서 이제 개발하는 걸로 생각을 해야 될 것 같고 이 의견은 개발적으로는 동호 씨가 그렇게 하는 게 맞겠다 생각을 하거든요. 그래서 그거에 대해서 좀 더 얘기해보면 좋을 것 같습니다.

언제까지 어떻게 말해야 되는지? 뭐 이제 얘기해 봐야죠. 그게 오디언스 뷰더가 없으면 그 노드가 빠지게 되고요. 아마도. 그 노드가 빠지거나 아니면 몇 개 일부 이벤트만 잡아놓고 저희가 만들어 놓은 거 몇 개만 이벤트 잡아놓고 임시로 노드를 올려야 되겠죠. 근데 그거 비동기로 할 거냐 아니면 그냥 다 맞춰서 진행할 거냐고 얘기를 많이 될 것 같습니다. 이게 지금 어느 정도 비담을 잡고 있는 거예요?

3주요. 3주? 네. 뭐 대중이 없지 않을까 싶은데요. 3주. 배포는 9월 15일로 일단 생각하기는 했었어요. 네. 근데 지금 말씀하신 거 들어보니까 9월 중에 뭔가 워크플로우 쪽에서도 오디언스 개발이 있으면 사실 맞추는 게 맞긴 하죠. 근데 오디언스 목록을 만들 때는 어떻게 만들려고 하셨어요? 크리에이트하는 UX라던지? 그럼 지금부터는 거의 다 했으니까 뒷부분은 디자인 보면서 진행을 해버릴까요? 10분 남았으니까

저는 화면을 끄고요. 현진님 걸로 바꿀게요. 제가 해드릴게요. -저 음식은 되게 눈이 안 보여가지고. -응. -돋으셨나요? -응. 일단 볼 때가 빠져서 오디언으로 1댑스는 더 커지고 개별적인 오디언스를 선택하면 그 후에 관리를 할 수 있는 개념입니다.

오디언스는 기본 오디언스로 제품을 기본적으로 제공하는 오디언스와 있고 이 기본 오디언스 탭이 없으면 사람이 커스텀해서 만든 오디언스라고 표현을 했는데 AI 개념이 생긴 탭으로 하나가 더 추가가 될 것 같고요. 이 오디언스에 대한 모수와 마지막 갱신액 그리고 사연처 부정 매출 활성화하고 이 오디언스를 관리하겠다 관리하지 않겠다 이 요구를 판단합니다. 여기까지는 다. 해당 오디언스는 활성화되었을 시에는 복제만 가능하고요.

그리고 활성화하기 직전에는 수정, 삭제, 복제가 모두 가능하고 활성화했을 때는 수정과 삭제는 불가하고 복제만 가능하고 활성화를 했는데 사용처가 없는 것이면 수정만 불가능하고 삭제만 복제는 가능합니다. 비활성화할 때는 수정은 불가능하고 삭제, 복제 가능하고 한 번이라도 활성화한 적 있으면 수정이 아예 안 되는 기능이고요. 연결된 캠페인이 있으면 삭제가 안 됩니다. 복제는 모든 상태에서는 항상 가능합니다.

-목록의 누적매출 같은 경우는 저희에게 지표율이 끝나고 나서 오늘 수정됐으면 좋겠어요? -어 당연하죠. 누적매출은 제가 디자인하면서 오디언스 관련해서 성과를 판단할까 했을 때 그러면 사람들이 오디언스를 활용했을 때 최종적으로 기대하는 건 이걸로 보고 캠페인이 얼마나 벌었을 것 같아요. 그래서 이 오디언스를 관리한다는 개념을 생각을 했을 때 그럼 뭘 기준으로 관리를 할까

그래서 저는 누적 매출을 높은 수는 보고 어 그럼 이거 높으니까 얘는 활성화 계속 해둬야겠다 얘는 남내 굳이 필요 없겠네 하면서 비활성화 해야겠다 판단이 될 것 같아서 외워놨지만 내부에서 얘기하고 출문성이 변경될 수 있는 상황입니다. 오늘 얘기했던 흐름대로면은 이제 사실 오디언스는 트리거로만 존재해야 되기 때문에 저런 식의 이제 누적 매출이 얼마다 라는 거는 사실 워크플로우에서 가져가는 게 더 나을 수도 있죠.

네. 일단 오디언스 목록을 이렇게 보여주고 오디언스 추가를 눌렀을 시에 기본 오디언스라고 해서 제품을 기본적으로 제공하는 오디언스와 내 오디언스, 내가 만들었던 오디언스, 그리고 csv 업로드를 통해서 공격을 업로드할 수 있고요. 직접 만들기를 하면은 I am 이렇게 열 값의 상태에서 직접 조건 오디언스 명을 세팅하고 조건을 설정할 수 있습니다.

아까 지나친 것 같은데, 리스트랑 정적인 것과 동적인 게 어떤 기준으로 나뉘는 건가요? 지금 여기 보이는 건 딱 동적인 것 같은데 이 두 개는 동적이고 CSP 영역만 정적이라고 생각해요. 그걸 따로 화면상에서 구분 안 한다고 그랬죠? 응 그냥 고객에게 굳이 그 동작 정책 개념을 알릴 필요는 없다고 생각해서

그러면 csv 업로드 한 거는 기본 오디언스 간에 내 오디언스에 들어가는 건가요? 아니요 기본 오디언스는 제품 기본적으로 조건값이 세팅하는 값이고 내 오디언스는 방금 직접 만들기 동작 구현이 같은데 내가 직접 오디언스 조건을 설정하는 거고요. csv는? 은하님 말씀이 맞는 거 같은데요. 왜냐하면 지금 마케터가 타겟팅해서 내 오디언스처럼 커스터마이징을 한 거잖아요. 내 오디언스에 들어가는 게 맞죠.

내 오디언스에 들어간다고 생각하면 되네요. csv로 업로드 되면 활성화라는 게 없잖아요. 온오프라는 기준이. - 활성화하는 개념이? - 온오프 개념이 없어지잖아, CSV면. 아니죠. CSV로 이렇게 해서 올려지면 이렇게 항목이 추가가 되면 그때 활성화할 거나 비활성화할 거나 선택하고. 차이가 뭐예요? 활성화랑 비활성화. 활성화는 내가 이걸 계속 옵적으로 그 C계열을 찍고 일관될 개최하는 걸로. CSV로 업로드하기에 C계열로 TK를... 그 모수 자체를 불러올 거고 그 모수..

찍는 건 다.. 모수가 고정이잖아. 동호시가 왔다 갔다 하는 게 없지 않냐 이거고 근데 제 생각에는 뭐 여기서 또 제 생각하는지 모르겠는데 지표라는 게 사실 그 지표 말고도 뭐.. 매출에 대한 지표를.. 를 찍겠다 하면은 그것도 가능한거고 근데 그럴거 같기는 해요 이게 타겟팅을 처음에는 오늘 날짜로 했는데 일주일 지나보니까 그 타겟에서 벗어날 수 있긴 하잖아요

근데 뭐 예를 들어 벗어났다는 표현이 뭐 진짜 뭐 회원 이탈했다 비회원이 되어버렸다 라든지 완전한 이탈이 발생하면은 그거에 대한 예외사항이니까 이거는 뭔가 표시를 해준다던지 그래서 뭐 모두 자체가 처음에 10명이었는데 지금 8명이 됐다라든지 뭐 이런걸 표기를 해줄 필요는 있을 것 같다는 생각이 들어요 지금 얘기 들어보니까 그러니까 그렇게 변화되는 정책도 정책을 더 써야 되겠네요.

그 CSV에 대한 걸 말씀하시는 거죠? 네, CSV에서 뭐 삭제를 했다. 그런 삭제가 되나요? 뭐 삭제를 안 하더라도 표기는 해줘야 되지 않을까 라고 저도 지금 생각하고 있는 거예요. 네, 그런 부분 좀 많이 빠져있는 것 같은데, 인액티브랑 액티브의 차이가 지금 그것도 명확하지는 않은 것 같아요. 제가 보기에는 결국 겨우라고 얘기하는 거는 이제 트리거나 이런 걸 뺀 개념이기 때문에 말씀드린 것 같아요. 그러면 이제 지표에 대한 것 같아요.

그럼 지표를 어떤 걸 확보할 거냐, 이거 다시. - 그 얘기로 들어가서. - 맞아요. 여기 추가하는 빌더 하면 저희 워크플로에서 만들어지는 거랑 거의 동일하게 되어 있다고 인지하면 되는 거예요? - 저희가 아니라 똑같은 걸로. - 아예 똑같아요? 아 지금 그렇게 되어 있냐고 물어보는 거예요? - 그렇습니다. - 아 그래요? - 직접 만들기 말하는 거죠? - 네. 저 눌렀을 때는 현재 똑같아요. 저희는 이걸 물어보고 그랬어요. 음. 오디언스 명은 추가된 것 같아요.

둘이 그냥 붙여야 돼. 그냥. 네. 근데 보고 하신 걸로 알고 있긴 한데 저희 워크플로 오디언스 빌더에 어떻게 되는지 똑같이 구현하셨다는 걸로 이해해도 되는 거 아니에요? 아니요. 아, 달라요? 몰라. 몰라. 그때 저한테 물어보고 화면 가져가신 걸로 제가 기억해가지고. 아 화면 보긴 한데 전체를 상봉은 안 하고 근데 은하님 화면이 먼저 나온 거니까 우리는 그냥 그 디자인 보고 똑같이 가져가면 되는 거겠죠? 모달 뷰로 되어 있긴 한데 저희는 화면으로 바꾸는 작업들만 있는 거 같아요

다만 그 CDP 관리 주체에 대한 표시가 있거든요 그것도 고려를 해주셔야 될 거 같아요 CDP가 아닌 것과 로컬 데이터들을 구분해서 표시를 하고 있거든요 그런 부분들 왜냐면 관리 주체를 바꾸는 건 아니고 다 쓰게끔 하겠다는 건 변경되는 사항들이라서 그런 인수인계가 필요할 거 같아요 - 천연이죠. - 네, 그걸로 인수인기가 필요할 것 같아요. - 그게 뭘로 아직. - 아니, 지금 오늘부터 같이 하기로 한 거잖아요. 오늘부터 하면 되는 거죠, 이제. - 그러면 오디언스에서 비회원도 다를 수 있게 돼야 될 텐데. - 네, 네.

그것도 같이 고민을 해야 될 것 같습니다. 저랑 같이 하시죠. 그렇습니다. 일단 개별 오디언스 클릭하면 이 오디언스의 조건과 흐름, 성과, 명단을 확인할 수 있고요. 조건 같은 경우에는 활성화, 액티브할 후에는 조건을 수정할 수 없고, 수정하고 싶으면 같은 조건만 새 오디언스 만드세요. 그래서 새 오디언스 만드는 복제본이 떠집니다. 복제본은 조건을 그대로 가져와서 이 흐름과 성과, 명단 같은 경우에는 갱신해야만 가져오고

그것만 그대로 파피한다고 생각하시면 됩니다. Q. 어떤 문제를 해야 할까요? Q. 이렇게 활성화하기 전에는 조건을 수정할 수 있고요. Q. 흐름을 보시면 전체 메시지 캠페인 자성과 1회성 구분을 해볼 수 있고 Q. 5연수 규모의 변화의 추이를 확인할 수 있고 Q. 이 변화 추이와 구매 단계의 이동은 1배치로 돌아가지만 Q. 사용자는 7일 14일 30일 90일 혹은 기간 선택해서 확인할 수 있습니다.

구매 단계 이동 같은 경우는 미구매, 초구매, 재구매, 고반복, 이걸 포트 히트넷 뷰로 보호했는데요. 이 미구매에서 표면 이탈한 고객은 어떤 행동에서 이탈을 했는지 확인해서 캠핑을 만들 수 있고 이 미구매에서 유지가 된 고객이 몇 명인지, 미구매에서 초구매로 이동한 고객이 몇 명인지 확인할 수 있습니다. 잠깐만요 아까 지나갔는데 우리가 하위여정에 대한 가변값도 현진님이 세팅하신 게 있었잖아요

그거 잠깐 볼까요 클릭했을 때 현재는 그쵸 미구매, 초급매, 재구매 고반복이었는데 이게 현진님 아이디어에서는 각각의 것들에 대해서 장바구니에서 멈췄나요? 이탈했나요? 상품주에서 이탈했나요? 진입만하고 이탈했나요? 아예 활동이 없나요 정도로 아이디어를 짜셨다. 그래서 아까 PRD가 그냥 넘어가긴 했는데 이게 좋을지 아니면 혹시 더 좋은 뭔가 하위 가변값이 있으면 그걸 써보고 싶다까지였습니다. 조그맨 안하네. 일단은 근데 무시 갖고 있는 건가요?

기존 페이지 1. 근데 이거 그냥 워딩은 이탈로 쓰는 게 더.. 직관적일 것 같긴 해요. 멈춤으로서 좀 어려워서. 아 그리고 좀 궁금한 게 지금 이게 오디언스 한 개에 캠페인 여러 개로 지금 되어 있잖아요. 조관계가. 근데 만약에 워크플로우 한 개에 오디언스 여러 개 쓸 수 있거든요. 그럼 그런 것도 다 목록에 적재된다고 생각하면 될까요? - 캠페인 안에 오디언스.. - 오디언스 트리가 하나 들어가고 필터도 들어가는 거는 그건 따로 관리되는 거였는지가 궁금했어

한 워크플러에 오디언스 여러 번 들어갈 수 있는 거잖아요 - 한 워크플러에? - 네 오디언스 필터가 있는데 오디언스랑 같은 걸로 가니까 - 근데 뭐.. - 잘 이해가 안 되는데? - 상관없을 거 같은데? - 상관없어요 - 하나로 봐도 된다. - 필터는 어차피 그냥.. 안에서 필터링하는 거니까? 어 죄송해요. - 네, 공짜로. - 관리해줘야 되는 거는 - 칠거에 있는 것만, 아니면 목록을 참조한다는 거고 - 오케이 오케이. - 그럼 이게.. - 그냥 따로다? 그래서 지금 디자인이 고쳐져야 돼요. 디자인 지금 오디언스 필터에 보면 목록 가져오는 게 있잖아요.

그죠? 네 맞아요 그거 뺀다는 거예요? 그것도 애매한.. 그게 있는 게 더 애매한 것 같거든요. 무슨 말인지. 가져온다는 건데 가져오는 게 정확히는 아니고 그 것만 가져오는 그런 느낌이 들 것 같아서 없애버리는 게 나을 것 같아요. 네 알겠습니다. 다 보셨나요? 네 더 있으신 거. 네 그래서 오디언스 성파로운 편이지만 연결된 게 어떤 거? 저는 처음에는 매출로 판단을 해서 전환이 구매 전환인지 가입 전환인지

이걸 또 매출이 얼마나 된다는지를 요약하는 거 생각을 했는데 그 말씀을 계속하신 것처럼 오디언스만의 지표로 성능을 그 규모 받게 될 것 같아요. 명단 같은 경우에는 1단위로 배치가 되는 것만 사용자가 직원 갱신을 통해서 수동 갱신을 할 수도 있고 즉 과거에 명단 정보는 아마 있겠지만 화면 단에서 보여주는 것까지는 고려는 안 했어요. 그 기준에 그 망각이 있는 방법 고객관리업 동행하게 클릭하시게 공유한 히스토리를 할 수 있습니다.

그리고 여기서 아까랑 동일하게 오른쪽으로 바로 캠페인 만들기로 해서 메시지 발송가세요. 명단 불러오는 게 뭐라고요? 명단 불러오는 게.. 현재 스냅샷으로만 항상 불러오고 아까 은하님이 질문하셨던 3일 전, 7일 전 그때 명단도 다 불러올 수 있나요? 라는 질문에 대해서 화면 레벨에서는 아직 설계된 게 없다는 답변이었어요. 이미 요구사항에 명단이 있긴 있네요. 스냅샷 기준으로. 네, 스냅샷 기준으로는 명단이 있어요. 그리고 그냥 계속 현실적으로 스냅샷 보여준다고 해서.

맞아요. 근데 저 궁금한 게 만약에 오디언스 빌더를 같이 공유하게 되면 푸시 쪽에서는 당연히 비에어는 안 되잖아요. 그럼 그 막혀 같은 화면이 막혀 있게끔 정, 뭐 그렇게 UX가 흘러지게 될까요? 여기서는 메시지니까 비회원 사용 못하는데 비회원이 있잖아요. 필드로. 그때는 비활성화 처리되는 그런 걸로 가능을 생각하는 건지 궁금해요. 비회원이라는 스펙을 우리가 아까 녹이기로 했으니까 그걸 상정해서 지금 나온 질문인 것 같거든요. 그걸 우리가 스펙으로 적용시켜버리면

지금 여기서도 3회 이상 조회 미구매에서 회원 아이디들이랑 비회원 아이디들이 존재할 것이다 이 얘기인 거죠. 가설이. 네. 그리고 빌더에서는 비회원 설정해놔도 비행한텐데 그런 건 어떻게 해야 될지가 추가적인 고민이네요. 이걸로 했을 때 만약에 비회원 회원이 섞여 있는데 제품이 새색 캠페인에 구매를 하는 게 아니라 비회원 지금 필요하고 싶지 않아. 근데 길러에서는 선택하는 화면도 공개될 것 같아요. 비회원 실드가 있을 텐데 비회원 너무 스페이 큰데. 비회원 생활 시킬 거냐 이런 것도 너무 여기저기 다 들어가는 게 비회원이라는 개념이에요. 한번 닮아야겠습니다.

같이 공유하는 만큼 푸쉬에서만의 UX를 잘 고려해서 여기에 또 반영을 해야 되는 것이 있을 것 같아요. 우리는 더 유연성 있게 만들어지잖아요. 빌더가. 푸쉬에서는 쓸 수 있는 게 한정적이니까 그걸 또 어떻게 할 것 같아요. 사실 메시지 발송만 생각하면서 했을 때는 비회원이 저한테는 그렇게 중요하지 않았었는데 솔직히 말하면. 그렇죠. 그게 맞죠. 원래는. 근데 일단 오디언스가 메시지 발송 비회원까지 생각해서 가질 필요는 없을 것 같아요. 오디언스 자체가 어떻게 할지 정체를 정하고 메시지 발송에서는 비회원은 어떻게 할지 아까 말한 할인 모듈에서는 어떻게 할지 좀 다르지.

근데 지금 화면을 공유한다고 하면 그게 들어간다니까요. 그러니까 그게 들어간 다음에 비회원을 어떻게 처리할지는 발송해서 그거는 생각하는 게 나을 것 같다. 오디언스 트리거 조건에서 페이지뷰 3회 이걸로 했어요. 그러면 오디언스 목록이 생기는 걸로 지금 생각하고 있는데 거기에 조건은 생기고 거기에 회원도 포함이 되고 비회원도 포함이 되거든요. 페이지뷰 3회를 바꿔서 하는 거거든요.

그러면... 그러면... 구별 안 할 수가 있겠나? 근데 그 노드에서는 다 포함되게 할 거라는 거잖아요. BAYERY를 해야 되는 거고 오디언스 빌더에서는 그게 뽑힐 테니까 BAYERY에서 그럼 넘어가서 그 액션 노드를 탈 때 그거를 격의 정책에서 정하는 게 낫지 않나? 근데 여기 지표 같은 것도 보여주고 해야 될 텐데 여기 지표 맞춰면 여기 지표를 보여줘야 돼요

메시지에 관련된 지표를 드릴 테니까요 여기서요? 네 제가 한번 정리해볼게요 제가 이해하고 있는 게 맞으면 다 이해하는 시인 것 같아서 민우님 말이 전 좋았던 점이 뭐냐면 실제로 액션 노드를 우리가 세팅을 할 때 이게 메시지에 관련된 액션 노드야 그러면 이 순간에 어차피 비회원인 애들은 필요가 없을 테니까 자연스럽게 시스템적으로 그냥 회원인 애들만 집계를 해가지고 걔네들에 있는 지표들만 쫙 보여주면 되는 거잖아 근데 지금 너네가 얘기하고 있는 이 화면

즉 메시지에 관련된 CRM에 대한 화면이니까 여기서는 굳이 비회원에 대한 정보를 보여줄 필요가 있어? 라는 걸로 저는 이해했어요 이 화면이 메시지 발송 화면이 아니라 오디언스 화면이잖아요 오디언스 공목을 보여줘야 되는 거예요 맞아요 너무 헷갈리네 오디언스는 오디언스 목록만 보여주면 되는 거 아니에요? 오디언스 목록에 회원만 있었는데 비회원의 균형을 추가시키자는 얘기였고 현재는 보라델데 메시지 발송만 있어서

자동화만 있어서 회원만 있었는데 오디언스의 비회원 균형을 종목시키면 저는 그래서 사실 아까 대표님이 계속 그 얘기 했잖아요. 지금 계속 캠페인을 생각하고 이게 짜여진 것 같다. 다른 것도 생각해야 된다 이러는데 저는 반대로 아예 캠페인까지도 드러내고 독립적으로 오디언스만 생각하고 일단 기획하는 게 어떤 이야기거든요. 그러면 걔가 독립적으로 했으면 나머지 다른 거 붙이는 건 사실 우전성이 없을 거 아니에요.

근데 그러면 오히려 비회원을 구분해서 보여줘야 되는 거 같아요? 맞아요. 원래 처음에 그 얘기를 한 거예요. 근데 이제 표시에서는 메시지랑 연계를 하고 싶으니까 그거까지가 오디언스에 들어가야지 가치가, 가치 전달이 된다고 생각을 하니까 지금 계속 고민을 하고 있는 거죠. 그러니까 뭐 비회원이어서 캠핑 못 만든다 뭐 이런 거까지는 아니더라도 그냥 구분 정도는 보여주는 게 맞는 거고 처음에 제가 오디언스 설명 드릴 때 오디언스는 오디언스 만으로도 동작할 수 있는

캠페인이랑 별개로 독립할 수 있는 서비스 기능이어야 된다고 말씀드렸잖아요 어쨌든 이게 푸시해서 관리하니까 그런 거고 오디언스 단독만 생각하면 깔끔할 것 같은데 사실 고객관리 관점에서 보면 메시지 발송은 고객이 중심이셔, 메시지 발송보다는. 그치, 그치. 그리고 오디언스에 조금 더 심층화, 액션도 빼버리고 그것만 좀 더 집중하는 것도 좋을 것 같은데요, 저는 오히려.

근데 근데 푸시 입장에서 좋은지는 잘 모르겠어요. 오디언스 쪽에서 생각했으면 맞는데. 제품팀 입장에서. 근데 독립적으로 그걸 한담하실 때 어떻게 할 것 같아요. 저는 그러면 지는 다 빼고. 오디언스는 넉넉한 리셋이. 처음에 좋은 얘기 말씀하셨잖아요. 고객 자산이라고. 맞아요. 그러니까 고객 자산으로서 고객 데이터만 관리하고 그 부수적인 거는 그 이외에 붙이는 거죠. 메시지 발송 이런 거 다 빼버리고.

여기에 사실 총 구매금액 이런 건 있을 수 있는 거죠. 그 유저에 대한 정보니까. 그 유저가 메시지를. 그 유저에 대한 메시지 발송을 얼마나 했고, 얼마나 받았고 이건 가능할 수 있는 건데 이제 오디언스 전체를 그렇게 고객 관리를 그렇게 하면 가능해지는 거죠. 고객 단위로 만약에 데이터를 관리하게 되면. 근데 그건 아니잖아요.

아닌 이유는 출발선이 현재의 CRM 모습에서 출발했기 때문이고요 네 캠페인 지표를 캠페인이나 오프플러가 들고 있지 고객이 들고 있는 거 아니니까 그래서 대표님이 약간 그러면 오지연 씨 지표 왜 필요하냐 이러는데 아까 얘기했던 것처럼 신규 유입이랑 이탈성도는 지표를 갖고 있는 거에 대해서 그것도 이해가 안 되시는거에요? 그러니까 뭔가 납득이 안 되시는거에요? 아니 아니요 그게 아니고 독립적으로 존재한다는 개념이 뭘까

그 말이 무엇인가 이 얘기인데 지금 저런 메시지 발송이나 이런 것들 워크플로우로 다 넘기자 이런 얘기도 이해가 안되고요 저는 근데 그게 워크플로우에 넘기든 데이터를 여기서 관리하든 뭐하든 아무튼 UX적으로 얘기를 해야 되는거에요 여기서 데이터가 저기 있든 여기 있든 얘는 갖고 오는게 그거는 개발일인데 독립적으로 계속 저는 이제 얘기가 나와서 하는거고 이게 캠페인 만들기가 있고 캠페인에 대한 게 기준으로 자꾸 하다 보니까

뭔가 제약사항이 있는 것 같으니까 아예 그냥 그런 제약사항 없이 독립적으로 오디언스만 생각해서 하면은 나중에 쿠폰이 됐든 하이머디를 됐든 그런 거 보시면 되거든요 같은 일이니까 그거 때문에 문제가 생긴 거 그것 때문에 뷰가 엄청 달라지고 UX 그려야 될 것도 많이 달라질 것 같아요. 사실 여기서도 탭으로 메뉴화해 놓은 메시지 캠페인

저런 게 이제 두 분 제가 이해한 게 맞다면 우선도가 좀 낮아지는 거고요. 아예 없애거나 사실 여기서 보여줘야 되는 거는 상품 상세 3회 이상 조회 미구매라는 고객 자산이 지금 성장하고 있어? 성장하고 있는데 얘네 총 매출이 얼마야? 평균 계산가 얼마야? 이런 식으로 고객 지표로서의 공통화된 이게 업셀링이든 CRM이든 어느 할 것 없이 다 공통적으로 들어가는 스코어 카드 개념에서 뿅뿅뿅 정보가 있으면 그걸로 충분한 것 같다. 로 이해했어요. 대신에 여기서 액션 버튼 같은 건 다 빼버리는 거고.

그리고 지금 할 수 있는 게 사실 메시지가 연결돼 있어서 메시지부터 시작하잖아요. 맞아요. 맞아요. 그러니까 나중에 저게 들어가고 프로모션 듣고 싶으면 프로모션 듣고 굳이 디테일한 지표가 저기에 안 들어가면 나중에 그걸 생각하시면 민우님은 저한테 추천해주셨던 게 해클이었고 사실 해클이 그런 식으로 되어 있긴 하거든요. 코어트 집단으로 세팅해놓으면 해당 코어트를 원하는 뷰나 원하는 지표 모델로 세팅해가지고 바라볼 수 있게끔 해놨어요. 그러니까 걔네가 조금 더 민우님 말씀하신 오디어스 개념이랑 좀 더 가까울 것 같긴 해요. 자산관리 개념에서.

내가 집단 세팅해놓고 얘네들을 내가 원하는 스코어 카드 개념으로 따다다 뾰불불불불불로 해놓고 볼 수 있다 이런 거죠. 민윤 씨가 얘기해주는 UX적인 거 각종 제외가 있는 건 기술적인 것도... 기술적인 거로는 저는 그러면 워크플로우에서 오디언스 트리거 을 통해서 오디언스를 만드는 상황이 된다 라고 하면은 그.. 그.. 그때 이제 회원기반의 오디언스 트리거가 있을 거고

그렇지 않은 트리거가 있을 텐데 그 조건들이 있을 텐데 그러지 않았을 때 이제 B-A-O는 어차피 표시가 되어야 되는 거잖아요 그건 맞죠? 네. 비회원을 표시하고 싶으면 표시를 해야 되는 거잖아요 그런 오디언스들은 기술적으로는 무슨 얘기를 해주신 거예요? 아니 그러니까 예를 들어서 오디언스 빌더 트리거가 있어요 그럼 지금 비회원 회원 얘기를 하다가

그게 들어가고 말고는 어차피 오디언스에 들어가야 되니까 포함되면 포함되는 건데 나중에 비회원을 그렇게 되면 캠페인 발송할 때는 어떻게 해야 되냐 그런데 그건 발송모드가 해야 될 일 아니냐 이거죠 왜냐하면 우리가 비회원 회원 아니면 비지터 아이디 아이덴티티가 통일화 되지 않았잖아요 회원 자체가 그게 통일화가 됐으면 내부에서 알아서 처리해서 다 발송 비회원은 회원이랑 매칭해서 보내고 했겠죠? 근데 안 돼 있으니까 그게 탁하고 들어오면은 그걸 발송노드에서 처리를 하든 이렇게 하는 거예요

그러면 제가 생각하기엔 기술적인 게 사실 만약에 메시지를 보낸다고 했을 때 비회원은 안 보내고 회원한테만 보낸다는 점이 있으면 되는 거잖아요 저는 이게 지금 자산관리 측면에서 어떤 지표들을 빼고 아예 그냥 회원의 이동, 회원의 상태바를 이동 이것만 바라보겠다. -이것도 가능한 일이에요. -네, 맞아요. 근데 거기다가 지표들 다른 걸 또 넣겠다. 이것도 가능하다고 말하는데 지금 얘기 때문에

무슨 정책이나 기술이 뭐하고 뭐하고 이런 것 때문에 지금 여기서 UX적으로 하려고 했던 거를 제한할 필요는 없다고 -아, 이해했습니다. -네, 네. 그래서 지금 저렇게 탭 나눠 놓으셨고 저게 다 탭을 더 추가하면은 예를 들어서 이 오디언스가 참조했던 어떤 액션 노드들에 대한 것들 혹은 워크플로우에 대한 탭들을 이렇게 나눠서 보면 될 거란 말이에요? 네, 네. 오히려 사고의 확장이라고 표현하고 싶은데 저는 이제 요거를 설계 같이 디자인하면서

맞긴 해요. 메시지 CRM 쪽으로 생각을 하면서 이 그림을 그렸기 때문에 그 사실은 이제 앞으로 이제 워크플로우 쪽에서 산식 같은 걸 통해 가지고 뭐 업셀링 이라든지 뭐 쿠폰 할인이나 뭐 이런 것들을 저희가 박을 수 있겠죠 추가적으로 여기다가 더 표현할 수 있을 것 그래서 더 확장될 것 같아요 근데 지금 일단 페이즈 1 단계에서는 CRM에서 시작한 게 또 맞기 때문에 요 화면으로 지금 설명을 드린 거고 맞죠? - 그러니까 다 분이 지금 엑스점이니 아닌 거 같아요. - 맞아요.

그래서 여기서 어떤 지표들을 보여주고 싶냐, 뭐하냐, 이거는 기획자들이 결정을 하셨고요. - 네. - 말씀하신 대로 지표들을 그냥 가져오면 그만. - 맞아요. 맞아요. - 그리고 아까 발송 명단에서 비회원이 들어가면 메시지를 보낼 수 있냐고, - 왜 비회원이냐고, 그런 비회원 제안을 시키고 - 그렇게 하면 되죠. - 되는 거잖아요. - 맞아요. 맞아요. - 그래서, 그러니까 그래서 저 버튼을 또 뺄 이유가 있냐고, - 아, 네네. - 그러니까 지금 얘기가 마치 기술적인 것과 여러 가지 복잡한 얘기들 때문에,

- 아, 복잡하다. 그냥 간단하게 가자. 이렇게 가신 거면, 목록도 필요 없어요. - 사실 그냥 오디언스 목록 뭐하러 왔는데, 그래서. - 네. 근데 구독책이 어떻게 되는 거고, 없앨프시 안 쓰는 경우에는 화면이 바뀌고 이렇게 되는 거예요? 잠겨있고? 근데 그걸 고려를 해야지 현재 시점에서 영향을 받는 거 아니에요? 제가 드리는 제품이 있었는데 그거였어요. 단순하게 하고 싶으세요? 진짜 극단적으로 단순하게

그럴 수 있어요. 근데 지금 어쨌든 그 저 뭐냐 오디언스에 대한 걸 객체화시켜서 별도로 관리하겠다는 거는 있는 거잖아요. 그게 지금 제일 핵심이고. 그 다음에 여기서 구수적으로 뭔가 보여줬는데 뭘 보여줄 거냐. 지표는 보여줘야 되는 거 아니냐. 지표 어디까지 포함할 거냐. 이거 여기서만 지표 포함할 거냐. 액션 취한 거까지 다 보여줄 거냐. 이런 얘기들이 이제 기획적으로 결정할 거냐. 그러면 완전 동의합니다. - 네. - 네.

결국에 저는 오디언스에서 비회원을 같이 관리할 거냐 안 할 거냐 그 결정에 따라 다를 것 같아요. 핵심적인 결정. 비회원도 다룬다는 거죠? -다라야 한다는 거죠. -다룬다. 다루는데 저렇게 메시지처럼 회원만 다루고 있는 애들은 뭐 리액션적으로 안된다고 안내를 하거나 하면 될 것 같아요. 네 그러면은 저 명단 봤을 때 고려할 게 추가로 생긴다는 거죠 그러니까

그냥 회원이냐 비회원이냐 네 그런 거 추가돼야 되고 저 1120명이라고 했을 때 저게 명이 아니라 오디언스 발생 건수? 이렇게 표현되어야 될 수도 있어요. 아니면 명으로 표현하되 누적일 수도 있다는 것을 고객사한테 전달하던가. 유니커 숫자가 아니니까 그 말씀하시는 거죠. 3페이지 3회 조회 미구매라고 했을 때 유저만 다룰 거면 그 3회 이상 미구매를 어디서 몇 번을 하든 유니커로 한 명 뽑으면 되는데

그게 아니라 비회원까지 구분을 해서 그러면 저 3회 이상 조회 미구매한 이벤트 건수가 되는 거죠 사실은. 그 중에 회원이 여러번 했을 수도 있고 아니면 비회원이 여러번 했을 수도 있고 하니까 그런 걸 고려해야 된다는 거예요. 그거 하기 싫으면 아예 다 빼버리고 오디언스만 관리하던지 다 하라는 것도 아니고 그렇다고 지금 뭐

그 정도? 네, 그렇습니다. 이해했습니다. 디자인적으로 더 보여줄 게 있나요? 혹시? 끝이죠. 여기까지. 다음 일정을 어떻게 잡는 게 좋을까요? 일단 오늘 여러분들 해주셨던 의견들 모아 모아 잘 모아서 PRD 한 번 더 버전 0.7여성 0.8로 올리고 한 번 더 PRD 리뷰는 어싱크하게 받으면 되겠죠? 그 다음부터는? 네, 문서로 한 번 더 뿌리고 사실 그 다음부터는 디자인 레벨에서 저희가 싱크앤롤란을 하는 게 더 중요할 것 같거든요 맞아요

그 선택에 따라서 UX가 엄청 달라집니다 그 선택? 그 선택이라고 하면? 아까 단순화 할 거냐, 극강에 유연함을 할 거냐, 극강에 단순화 할 거냐 그 수가 제 선택, 오디언스만 취급할 거냐, 지표까지 다 해서 확정성 있게 고려할 거냐? 근데 아무리 생각해도 그런 생각은 들어요 그러니까 현재 우리가 1단계라고 하면은 당장의 워크플로우는 동작하는 그런 프로덕트는 아니잖아요

그러니까 반대로 CRM, 알파포시는 동작하는 프로덕트인 거고 그러면 우리는 당연히 오디언스라는 기능 개발권을 녹일 때 동작하는 프로덕트에서 같이 전달해야 되는 게 1순위이기 때문에 당연히 개발 시기야 겹친다 하더라도 당장 고객한테 서브를 할 거야 이 가치를. 그 관점에서는 EdgeEasy에서 이미 서브하고 있었던 해당 오디언스한테 메시지 캠페인 발송할 수 있어요. 저는 이것까지는 EdgeEasy 정책들을 가져가고 싶기는 해요. 이거는 기존에 우리가 학습되어 있는 가치를 지금 굳이 뭔가 뺄 필요는 없으니까요.

다만 아까 말씀드렸던 것은 이제 개발하는 단계이다 보니까 앞으로 여러가지 메시지 뿐만 아니라 쿠폰 할인 개념들도 들어올 수 있겠다 그때 들어온 대로 녹이면 되지 않을까 적용하면 되지 않을까 그리고 다 같이 얘기하기 전에 FCT 내부에서도 한 번도 싱크를 맞췄으면 좋겠다고 생각합니다 그 핵심지표 얘기를 많이 하셨는데 저도 약간 공감 못하고 그리고 그 부분이 예전에 푸시길이 얘기했었을 때도 이거 로어스는 이거 있는 거 같은데

나중에 노드 연결했었을 때 그게 꼭 전환이 구매 전환이 아닐 수 있는데 오디언스의 종류적인 지표를 얘기해야 되는 거 아니냐 했는데 다 동의를 하셨었거든요. 근데 갑자기 또 화면이 달라져 있잖아요. 그러니까 저는 여기 와서 또 뭔가 새로운 싱크를 맞춰야 되는 상황이 된 거 같아요. 그때 이해를 다 했어야 하는 거 같고 맞아요. 그래서 그런 차원에서 저희끼리도 한번 싱크 맞추는 게 먼저 있었으면 좋겠어요. 맞아요. 사실 문서로 보면 너무 양이 방대하고 제가 말은 되게 쉽게 던지잖아요.

버전 올렸으니까 업데이트 확인해보려고 하긴 하는데 화면 레벨에서 더더욱 유심히 봐야 하는 것 같기는 합니다. 여기까지 할까요? 네. 고생하셨습니다. 감사합니다.