Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[123]동네 커피샵도 사이렌 오더를 쓸 수 있을까

9,013 views

Published on

[123]동네 커피샵도 사이렌 오더를 쓸 수 있을까

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

[123]동네 커피샵도 사이렌 오더를 쓸 수 있을까

  1. 1. 동네 커피샵도 사이렌오더를 쓸 수 있을까 허형 나동진 Lunchclass
  2. 2. 1. Overview
  3. 3. Siren Order 사용해 보셨나요?
  4. 4. Siren Order 모바일 주문 서비스 I want coffee.
  5. 5. Siren Order 모바일 주문 서비스 Order & Pay
  6. 6. Siren Order 모바일 주문 서비스 Going for coffee
  7. 7. Siren Order 모바일 주문 서비스 Get coffee
  8. 8. Siren Order 줄을 서지 않고 모바일로 주문/결제 출근길, Drive-thru, 자리를 잡고.. Etc. 편리함, 효율성
  9. 9. “집 앞 작은 까페에도 동일한 서비스를 사용할 수 있을까요?”
  10. 10. Another Order 예상 시나리오#1 서비스가 있다는 것을 인지하고
  11. 11. Another Order 예상 시나리오#1 App Installation 앱스토어에서 검색 후 설치
  12. 12. Another Order 예상 시나리오#1 Register & Login 회원가입 및 로그인 과정을 거처
  13. 13. Another Order 예상 시나리오#1 Order & Pay
  14. 14. Another Order 예상 시나리오#1 Get coffee
  15. 15. Another Order 예상 시나리오#2 흠…
  16. 16. Another Order 예상 시나리오#2 Instance(일회성) 소비를 위해 이러한 서비스를 이용할 수 없을까요? 대형 프렌차이즈 vs 소규모
  17. 17. Our Order 바라는 주문 시나리오
  18. 18. Our Order 바라는 주문 시나리오 앱 설치가 필요 없다면
  19. 19. Our Order 바라는 주문 시나리오 회원가입/로그인 생략
  20. 20. Our Order 바라는 주문 시나리오 간편한 주문/결제
  21. 21. Our Order 바라는 주문 시나리오
  22. 22. Our Order 바라는 주문 시나리오 어떻게 하면 될까요?
  23. 23. Overview 다음과 같은 내용을 이야기 하고자 합니다. • 일회성 소비를 위한 서비스를 가능하게 하는 웹 기술은 어떠한 것이 있는가? • 그걸 적용함에 따라 어떠한 문제들이 있는가? PWA Loginless Web Payment Push NotificationPhysical web
  24. 24. 2. PWA Physical Web
  25. 25. • 웹에서 앱과 같은 사용자 경험을 제공 • Service worker • Web page 로드 시 register • Browser와 별개로 돌고 있는 worker thread. • Browser가 꺼져 있는 상태에도 Push notification 가능 PWA(Progressive Web App) App 설치 없이 URL 접근으로 서비스를 가능하게 하는 솔루션
  26. 26. PWA(Progressive Web App) 정말로 URL 전달로 웹이 앱처럼 동작하는 것이 어떠한 상황을 만들어 낼까?
  27. 27. • 다수의 사용자에게 자연스럽게 URL을 전달할 수 있다. • 최소한 한번 이상 접속할 가능성이 높다. • 피드백을 받기 용이하다. PWA 모바일 청첩장
  28. 28. 1. SNS로 URL 전달 2. Webview Service worker, push enable PWA 모바일 청첩장 3. Webpage load
  29. 29. PWA 모바일 청첩장 4. Push notification 5. Event 참여 결혼식 전날 입니다. 이벤트를 진행합니다. 오늘 결혼합니다 :D
  30. 30. • PWA인지 모르고 사용했다. • 기존 모바일 청첩장과 다른 알림, 이벤트는 신선했다. • 모바일 청첩장을 앱으로 전달했다면 설치 하지 않았을 것이다. 결과 Feedback (43명) 일정 시기 이후 사용되지 않은 인스턴트 서비스, PWA 사용이 장점을 가지게 된다.
  31. 31. URL을 어떻게 전달할 것인가? 접근성을 높이기 • Physical Web(beacon) – bluethooth 설정, 무음 Notification • NFC – NDEF record, 사용자의 능동적 접근 필요 매장 안에 들어 섰을 때 모바일기기로 Menu에 대한 URL를 띄우고 싶다.
  32. 32. 3. Loginless
  33. 33. Loginless 또 다른 허들 • 54% - sign up 전에 떠나는 사용자 비율 • 92% - login 정보를 재설정 하기 전에 떠나는 사용자 비율 <출처: 2016 chrome dev summit sign-in on the web, Industry-Research-Value-of-Social-Login/janrain, blue> 회원가입과 로그인이 필요 없다는 것이 아닙니다.
  34. 34. Loginless • 기존에 비회원 주문이 있었습니다. • 사용자 정보를 입력하지 않고 서비스를 사용하려면? • 주문/결제 -> 알람 -> 수령 구간동안 사용자 구분이 필요 • data는 Indexed DB에 저장 data 만에 하나 사용자 정보에 문제가 생긴다면?
  35. 35. • 결제 후 물품 수령 구간이라면 사용자 정보에 대한 복원이 필요 • Platform device key를 사용할 수 있을까? • 복원 가능한 방법이 있을까? 사용자 정보가 유실될 경우 data Loginless
  36. 36. Mobile device 2 Diff Browser fingerprint를 이용한 사용자 정보 복원 Mobile device 1 • Browser level에서 device 를 구분하는 방법 • User agent (browser info, resolution) • Canvas 2D, WebGL • Javascript  web engine  CPU / GPU  rendering • Rendering 결과가 devic간 조금씩 다르다. • 추출한 data를 key로 사용 • 특정 시간, 구간에 사용자를 구분하는데 활용 Loginless <Canvas 2D로 text rendering시>
  37. 37. 4. Push Notification
  38. 38. Push Notification Revoke Permission
  39. 39. Push Notification O2O 서비스에서 중요한 핵심 요소 중 하나 기존의 O2O 서비스들 대부분 App push를 이용
  40. 40. Push Notification Serviceworker 에 의한 Push Notification 은 반드시 사용자로 부터 알람에 대한 Permision 을 구하도록 브라우저상에 구현됨
  41. 41. Push Notification 서비스 장애요소: 단 한번 BLOCK 당하게 될 경우 다시 알람을 허용할 방법이 거의 없음
  42. 42. Push Notification 사용자가 알람을 허용하게 될 확률: 5%
  43. 43. Push Notification 5% 를 위한 서비스를 만들 것인가? 브라우저를 뜯어 고칠 것인가?
  44. 44. Push Notification 다른 솔루션은 없을까?
  45. 45. Push Notification WEB Page Service Worker UserAgent registrtion Service worker registrtion Invoke dummy subscribe() User Allow subscribe() 솔루션: 느린 Invoke Permission 을 구하는 단계를 추가하여 사용자가 허용하지 않을 경우 실제 subscribe() 를 호출 하지 않도록 함 사용자가 거부하더라도 Permission 을 다시 구하는 revoke 가 가능한 상태로 유지
  46. 46. Push Notification 느린 Invoke 를 적용한 결과: 5% 50%
  47. 47. Payload Compatibility Push Notification
  48. 48. Push Notification Serviceworker 를 통한 Push-notification 은 App 처럼 Payload 에 Icon, image 등을 실어 보낼 수 있으며 메시지에 대한 응답을 구할 수 도 있다.
  49. 49. Push Notification 그러나 모든 브라우저 버전에서 Payload 가 정상적으로 표시되는 것은 아님.
  50. 50. Push Notification 브라우저 차별 하는 서비스를 만들 것인가?
  51. 51. Push Notification Service worker Push Service Application Server Push Query() Notify Resp() Notification Service 솔루션: Payload 대신 token을 이용해 Server 에 쿼리하여 데이터를 받아오는 방식으로 대체
  52. 52. 5. Web Payment
  53. 53. 인스턴스한 1회성 주문 시나리오에서 결제는? Payment • 결제를 위한 추가적인 앱 설치를 요구하지 않아야 한다. • Merchant 가 사용자가 원하는 지불수단을 제공해야 한다.
  54. 54. Payment 결국은 확장성의 문제 Merchant 가 지불수단을 얼마나 다양하게 지원해 줄 수 있는가?
  55. 55. 개발 플랫폼 Level 에서 제공할 수 있는 것 Payment • 웹으로 결제가능한 지불수단 추가를 최대한 쉽게 만듦 • Merchant 에서 지불수단 추가에 따른 인테그레이션 노력을 최소화
  56. 56. Payment 결제 호스팅 서비스들이 쉽게 지불수단을 추가할 수 있도록 해결해 주고 있지만....
  57. 57. Payment 지불방식과 관계없이 같은 인터페이스로 결제요청과 확인이 이루어지도록 할 순 없을까?
  58. 58. Payment • 지불방식과 관계없이 하나의 함수만을 사용 • 하나의 콜과 콜백안에서 결제요청과 확인이 완료 • 지불수단 추가가 단순하고 쉬움 • 새로운 지불방식의 FLOW 를 공부해야 할 필요가 없음 우리가 기대하는 수준
  59. 59. Web Payment 를 이용하면 가능할지도
  60. 60. Web Payment 에 대한 오해 Web Payment • 새로운 결제방식의 표준인가? => 아니다. 결제나 지불수단과 관련 없다. • 결제와 관련된 새로운 인증기술을 제공하나? => 아니다. 결제 인증과 아무런 관련 없다. • 웹 브라우저가 PG 역할을 대신해주는 것인가? => 결제 프로세스와 관련 없다.
  61. 61. 그렇다면 Web Payment는 무엇일까? Web Payment
  62. 62. Web Payment Web Payment • Payment Request API => 결제를 위한 프롬프트 UI 생성 / Payment Handler 로 구현된 결재 앱을 Activate 시킴 • Payment Handler  서비스워커 형태로 결제앱을 구현 가능하게 해주는 것
  63. 63. Web Payment Web Payment • Payment Request API => 결제를 위한 프롬프트 UI 생성
  64. 64. Web Payment Web Payment • Payment Handler  서비스워커 형태의 결제앱
  65. 65. Web Payment
  66. 66. PG 나 카드사의 결제사이트로 연결시켜 주는 것뿐이 아닐까? Web Payment
  67. 67. Merchant 와 결재 앱간의 통신이 네트웍으로 노출되지 않는 특징 Web Payment • 보안적으로 안전한 연결을 제공
  68. 68. 기존 URL-Redirection 방식 Web Payment
  69. 69. 피싱에 취약 Web Payment
  70. 70. 결제인증과 요청 및 확인이 이원화되면서 구조가 복잡해짐 Web Payment
  71. 71. Payment • 지불방식과 관계없이 하나의 함수만을 사용 • 하나의 콜과 콜백안에서 결제요청과 확인이 완료 • 지불수단 추가가 단순하고 쉬움 • 새로운 지불방식의 FLOW 를 공부해야 할 필요가 없음 우리가 기대하는 수준
  72. 72. 기존의 웹 결제방식은 콜백구조가 어려운 경우들이 존재 Web Payment 1. URL-Redirection 으로 결제 페이지를 로드하는 경우 - 기존 Merchant 페이지의 스크립트들이 UNLOAD 되어 버림 2. iframe 으로 결제 페이지를 로드하는 경우 - Merchant 와 결제사이트의 Origin 이 서로 다르기 때문에 데이터에 직접 접근할 수가 없 다.
  73. 73. Payment Handler 의 경우 Web Payment Web Browser Merchant ServiceWorker PaymentHandler Merchant 와 Pay앱이 서로 별개의 쓰레드이기 때문에 콜백구조가 깨지지 않는다.
  74. 74. 하지만 결국 PG가 PaymentHandler 로 앱을 구현해야만 하는거 아닌가? Web Payment
  75. 75. 페이앱에서 기존 PG 사들의 FLOW를 구현 Web Payment 결제요청과 결과확인은 PG와 관계없이 PaymentRequest API 하나로 제공
  76. 76. Payment • 지불방식과 관계없이 하나의 함수만을 사용 • 하나의 콜과 콜백안에서 결제요청과 확인이 완료 • 지불수단 추가가 단순하고 쉬움 • 새로운 지불방식의 FLOW 를 공부해야 할 필요가 없음 PaymentHandler 로 가능하다
  77. 77. 6. Future
  78. 78. Thank you

×