메뉴 건너뛰기

2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자


앞서 Best Practice #1의 방법으로 top 10 크래시를 수정한다면, 0.25% 이하의 크래시율을 유지하는 데에 매우 큰 도움이 될 것입니다. 전체 크래시율을 낮추는 것 외에도 주요 Userflow의 크래시율을 낮추고 관리하는 노력이 필요합니다.

로그인, 새로운 계정 등록 또는 구매 등 모든 앱은 비즈니스의 성공을 좌우하는 플로우가 있습니다. 나쁜 사용자 경험은 사용자 유치에 악영향을 주고 매출 감소와 사용자 감소로 이어집니다.


따라서 주요한 Userflow의 크래시율을 0.25%이하로 줄이기 위해 아래와 같은 방법을 활용할 수 있습니다.


1> 모니터에 적합한 3개의 Flow를 선정합니다.
앱에서 비즈니스 메트릭에 가장 큰 영향을 미치는 3개의 flow를 선정합니다. 이것은 앱에 따라 정말 다양할 수 있습니다. 가령 e-commerce 앱인 경우, 검색, 카트에 담기, 결제 등 구매를 중심으로 한 flow가 있을 수 있습니다. 금융 앱인 경우 잔고 확인, 예금 이체, 수표 지급 등의 주요 트랜잭션이 있을 수 있습니다. 일반적인 앱에서는 주로 새 계좌 등록이나 로그인과 같은 flow가 중요하다고 여겨집니다. 기존에 관리중인 KPI와 함께 이 메트릭에 직접 영향을 미치는 flow를 선택합니다.


2> Apteligent 모니터링 설정
SDK를 활용하여 다음의 코드 2 라인을 삽입하여 Apteligent의 userflow를 설정합니다.

예를 들어 사용자가 비행기를 예약하는 flow인 경우, 다음과 같은 두 라인의 코드를 활용합니다.

2-1.PNG

이 2 라인의 코드를 사용하면 각 플로우가 완료되는 데 걸리는 시간과 사용자가 플로우 내에 있는 동안 발생하는 모든 실패를 모니터링할 수 있습니다. App load와 같은 플로우는 별도의 설정이 없이도 모니터링 됩니다. 자세한 userflow 설정을 위해 다음 문서를 참고하시기 바랍니다.


3> Apteligent에서 flow 모니터링하기
User flow를 설정한 후 Apteligent를 사용하여 flow의 상태를 모니터링하고 사용자 경험에 악영향을 주는 에러의 우선순위를 지정합니다. Userflow Summary는 앱의 모든 flow 모니터링에 대한 정보를 보여주고 주요 flow의 상태를 이해할 수 있게 도와줍니다. 이 대시보드는 flow의 수, foreground시간(사용자가 해당 flow를 완료하기 위해 걸린 시간), 실패율, 리스크에 따른 기회 비용 손실을 보여줍니다. 앱을 릴리즈하는 모든 시간에 걸쳐 메트릭을 추적함으로써 좋은 사용자 경험 뿐만 아니라 바람직한 비즈니스 KPI를 얻을 수 있습니다.


2-2.png

     그림 1 Apteligent의 Userflow Summary Page에서는 앱에서 모니터링 중인 모든 flow를 보여줍니다.


4> Flow를 분석하여 userflow에 영향을 미치는 크래시 우선순위 정하기
Flow를 클릭하여 우선 순위를 결정하기 위한 주요 메트릭의 상세내용을 확인합니다. “Root Cause Analysis”탭에서는 특정 플로우에서 발생한 모든 크래시의 요약을 볼 수 있습니다. 탭 좌상단에는 메트릭 수치가 높은 플로우가 나타납니다. Userflow의 크래시율은(크래시로 인해 실패한 flow의 비율) 안정성에 연관된 측정치입니다. 전체 크래시율과 동일하게 각 주요 flow의 크래시율은 0.25%를 준수하도록 합니다.


2-3.png

      그림 2 Userflow 상세 페이지의 Crashed User Flows 탭에서는 특정 flow에서 발생한 크래시를 보여줍니다.


하단에 있는 Root Cause Analysis 탭의 리스트에서는 flow에서 발생한 모든 크래시를 보여줍니다.

각 flow에서 0.25%이하의 크래시율을 달성하기 위해서는 발생횟수가 가장 높은 크래시를 우선적으로 검토해야합니다. 각 userflow내에서 발생하는 top 10 크래시를 선정하여 각 스프린트에서 크래시를 해결하고 0.25%이하의 크래시율을 달성합시다.


Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr

Atachment
첨부 '3'
?

 


  1. 3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자

    3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자 크래시율과 더불어 app load time은 매우 중요한 지표입니다. App load time은 고객유치에 매우 밀접한 메트릭이자 모바일 앱에 접근하는 중요한 시간정보입니다. 연구에 따르면 app load time은 50%의 ...
    Date2018.02.19 ByNeO Reply0 Views584
    Read More
  2. 2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자

    2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자 앞서 Best Practice #1의 방법으로 top 10 크래시를 수정한다면, 0.25% 이하의 크래시율을 유지하는 데에 매우 큰 도움이 될 것입니다. 전체 크래시율을 낮추는 것 외에도 주요 Userflow의 크래시...
    Date2018.02.05 ByNeO Reply0 Views443
    Read More
  3. 1. 매 스프린트에서 Top 10 크래시를 잡자

    1. 매 스프린트에서 Top 10 크래시를 잡자 모바일 앱을 모니터링할 때 가장 중요한 지표 중 하나는 전체 크래시율입니다. 크래시율이란 전체 세션 대비 크래시가 발생한 비율을 의미합니다. 앱의 품질을 평가하는 데에 크래시율은 전체 릴리즈 프로세스에...
    Date2018.01.30 ByNeO Reply0 Views508
    Read More
  4. No Image

    모바일앱 최적화를 위한 7가지 (0)

    본 문서는 다음 문서를 번역한 글입니다. http://www.apteligent.com/white_paper/7-best-practices-optimizing-mobile-app-experience/ 이 문서를 게시하기 전에 모바일앱 모니터링 툴의 종류와 특성에 대한 개요를 작성하고자 하였으나, 많은  mAPM이나 ...
    Date2018.01.29 ByNeO Reply0 Views375
    Read More
  5. Is NoOps the End of DevOps? Think Again (2) 결론

    In conclusion, DevOps is forever DevOps의 완성형이라고 일컬어짐에도 불구하고 NoOps는 DevOps의 종착역은 아닙니다. 사실 NoOps는 DevOps를 통해 달성할 수 있는 혁신의 시작이라고 볼 수 있습니다. DevOps가 이름을 갖기 훨씬 전부터 시작된 NoOps...
    Date2018.01.02 ByNeO Reply0 Views343
    Read More
  6. Is NoOps the End of DevOps? Think Again (1) DevOps가 사라지지 않는 7가지 이유

     7 Reasons DevOps Is Not Dying 이제 DevOps의 시작에 대해 알았으니 본래의 질문으로 돌아가봅시다. NoOps가 DevOps의 종착역일까요? 그렇지 않습니다!  1. DevOps is a journey 어떤 Devopsdays에 참석하더라도 “DevOps is a jo...
    Date2018.01.02 ByNeO Reply0 Views398
    Read More
  7. Is NoOps the End of DevOps? Think Again (0) IT Operation, DevOps, NoOps 의 간략한 역사

    이 문서는 다음 링크의 글을 일부 번역했습니다. https://blog.appdynamics.com/engineering/is-noops-the-end-of-devops-think-again/ 제일 앞 부분의 DevOps와 NoOps 운동에 대한 논란은 관심있으신 분은 직접 링크를 따라가며 읽어보시면 좋을 것 같습...
    Date2018.01.02 ByNeO Reply0 Views496
    Read More
  8. Monoliths - Module, Allocation, Runtime Monolith

    이 문서는 다음 링크의 글을 번역했습니다. http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html 모노리스와 대비하여 마이크로서비스를 이야기하는 강한 트렌드가 있습니다. 그리고 모노리스를 마이크로서비스로 나누는 방법에 대...
    Date2017.12.13 ByNeO Reply0 Views627
    Read More
  9. No Image

    Microservices, Monoliths and Self-Contained Systems (3) Self-contained system과 결론

    Self-Contained System Self contained system은 모노리스와 마이크로서비스 중간쯤에 있는 블록형 아키텍처입니다. 여러 개의 마이크로서비스를 하나의 엔티티로 나타내면서도 모노리스보다는 작은 규모를 가지는 형태입니다. 만일 매우 연관성이 높아 ...
    Date2017.12.13 ByNeO Reply0 Views492
    Read More
  10. No Image

    Microservices, Monoliths and Self-Contained Systems (2) Microservices

    Microservices 상대적으로 마이크로서비스는 많은 장점을 가져다 주는 반면 단점이 적은 편입니다. 마이크로서비스는 커다란 어플리케이션의 일부분이라고 할 수 있으며 독립적인 어플리케이션이라고 할 수 있겠습니다. 예를 들어 웹 상에 스토어를 운영...
    Date2017.12.13 ByNeO Reply0 Views257
    Read More
Board Pagination Prev 1 2 3 Next
/ 3