我目前在一間經歷無數次後端演進的旅遊新創公司，在過去的幾年裡，我們陸續面對著各種挑戰，包括 Parse.com 的服務停止、為應對 Google maps 的收費政策而自建景點資料庫、漸進式導入 REST、使用 prerender 提升 SEO、使用 async 服務提升可用性、運用 CDN 快速讀取圖片、從 CSR 轉型到 SSR、導入電商服務，以及開始支援導購商品...等不計其數的功能。 每一項功能的實現不僅需要後端的協助，還要確保前端的相容性，以免讓使用者陷入無法使用服務的狀態。 而我在這次的分享中，將聊聊在只有一個專職後端的情況下，讓大家了解如何進行後端服務演進的挑戰和策略。

1. 如何在有限資源下實現十年的後端服務演進
Kewang, Funliday

2. Kewang
●
王慕羣 Kewang
●
JavaScript / Java
●
PostgreSQL / MongoDB / Elasticsearch / HBase
●
Git / DevOps
●
熱愛開源
Linkedin
Linkedin kewangtw
kewangtw
SlideShare
SlideShare kewang
kewang
Gmail
Gmail cpckewang
cpckewang
Facebook
Facebook Kewang 的資訊進化論
Kewang 的資訊進化論
devopsday taipei
devopsday taipei '17
'17
hadoopcon
hadoopcon '14 '15
'14 '15
jcconf
jcconf '16 '17 '18
'16 '17 '18
GitHub
GitHub kewang
kewang
Funliday
Funliday kewang
kewang
modernweb
modernweb '18 '19 '20 '21
'18 '19 '20 '21
coscup
coscup '20 '21
'20 '21
mopcon
mopcon '14 '20 '22
'14 '20 '22

4. 4
時間軸

5. 5
時間軸

6. 6
時間軸
●
從 Parse.com 停止服務開始

7. 7
時間軸
●
從 Parse.com 停止服務開始
●
因為 Google Maps API 開始收費

8. 8
時間軸
●
從 Parse.com 停止服務開始
●
因為 Google Maps API 開始收費
●
全世界的災難 COVID-19

9. 9
開始

10. 10
在我之前 (2014/9~2018/8)

11. 11
在我之前 (2014/9~2018/8)
●
Funliday 小有一點點名氣

12. 12
在我之前 (2014/9~2018/8)
●
Funliday 小有一點點名氣
●
剛募到天使輪資金

13. 13
在我之前 (2014/9~2018/8)
●
Funliday 小有一點點名氣
●
剛募到天使輪資金
●
後端從 Parse.com 轉到 heroku+MongoDB

14. 14
在我之前 (2014/9~2018/8)
●
Funliday 小有一點點名氣
●
剛募到天使輪資金
●
後端從 Parse.com 轉到 heroku+MongoDB
●
Google Maps API 開始收費

15. 15
在我之前 (2014/9~2018/8)
●
Funliday 小有一點點名氣
●
剛募到天使輪資金
●
後端從 Parse.com 轉到 heroku+MongoDB
●
Google Maps API 開始收費
●
Web,Android 殘破不堪

16. 16
從開發景點資料庫開始

17. 17
從開發景點資料庫開始
( 一條龍 )

18. 18
從開發景點資料庫開始 - 背景 (2018/9)

19. 19
從開發景點資料庫開始 - 背景 (2018/9)
●
Google Maps API 開始收費

20. 20
從開發景點資料庫開始 - 背景 (2018/9)
●
Google Maps API 開始收費
– 以 Funliday 的使用方式，每個月要幾十萬台幣

21. 21
從開發景點資料庫開始 - 背景 (2018/9)
●
Google Maps API 開始收費
– 以 Funliday 的使用方式，每個月要幾十萬台幣
– 我的第一個專案就是解耦 Google Maps API

22. 22
從開發景點資料庫開始 - 團隊 (1*2+0.5*2)
●
iOS 、 Web 、 Backend 、找錢、會計： 1
●
Android ： 0.5
●
Design ： 0.5
●
景點資料庫： 1 一個在日本 part time
一個還有正職工作

23. 23
從開發景點資料庫開始 - 實作

24. 24
從開發景點資料庫開始 - 實作
●
OpenStreetMap ：景點資料庫基礎

25. 25
從開發景點資料庫開始 - 實作
●
OpenStreetMap ：景點資料庫基礎
●
PostgreSQL ：關聯資料庫基礎

26. 26
從開發景點資料庫開始 - 實作
●
OpenStreetMap ：景點資料庫基礎
●
PostgreSQL ：關聯資料庫基礎
●
PostGIS ： GIS 新手入門

27. 27
從開發景點資料庫開始 - 實作
●
OpenStreetMap ：景點資料庫基礎
●
PostgreSQL ：關聯資料庫基礎
●
PostGIS ： GIS 新手入門
●
Elasticsearch ：全文搜尋資料庫

28. 28
從開發景點資料庫開始 - 實作
●
OpenStreetMap ：景點資料庫基礎
●
PostgreSQL ：關聯資料庫基礎
●
PostGIS ： GIS 新手入門
●
Elasticsearch ：全文搜尋資料庫
●
Redis ： Sorted Set 實作 autocomplete

29. 29
Elasticsearch - function score 自訂評分函數

30. 30
Elasticsearch - function score 自訂評分函數

31. 31
Elasticsearch - function score 自訂評分函數

32. 32
Redis - Sorted Set 實作 autocomplete

33. 33
Redis - Sorted Set 實作 autocomplete

34. 34
Redis - Sorted Set 實作 autocomplete
用 x00 區分是否為結果

35. 35
Redis - Sorted Set 實作 autocomplete
用 x00 區分是否為結果

36. 36
從開發景點資料庫開始

37. 37
從開發景點資料庫開始
( 有 team 的話 ...)

38. 38
有 team 的話 ...
●
OpenStreetMap+PostgreSQL+PostGIS ： 1
●
Elasticsearch ： 1
●
Redis ： 1

39. 39
接手後端開發並重構

40. 40
接手後端開發並重構
( 一條龍 )

41. 41
接手後端開發並重構 - 背景 (2019/9)

42. 42
接手後端開發並重構 - 背景 (2019/9)
●
找錢太花心力，要儘量減少開發工作

43. 43
接手後端開發並重構 - 背景 (2019/9)
●
找錢太花心力，要儘量減少開發工作
●
功能愈來愈多，技術債造成擴展困難

44. 44
接手後端開發並重構 - 團隊 (1*4)
●
iOS 、 Web 、找錢、會計： 1
●
Android ： 1
●
Design ： 1
●
Backend ： 1 都回歸團隊，還缺 Web

45. 45
接手後端開發並重構 - 實作

46. 46
接手後端開發並重構 - 實作
●
Callback hell

47. 47
接手後端開發並重構 - 實作
●
Callback hell
– Node.js 早期都是使用 callback 為主

48. 48
接手後端開發並重構 - 實作
●
Callback hell
– Node.js 早期都是使用 callback 為主
– 持續調整為 Promise (async/await)

49. 49
Callback hell

50. 50
Callback hell

51. 51
Callback hell
亂！有 thenable 又有 async/await

52. 52
接手後端開發並重構 - 實作

53. 53
接手後端開發並重構 - 實作
●
MongoDB schema 偏亂

54. 54
接手後端開發並重構 - 實作
●
MongoDB schema 偏亂
– schema 一開始沒有通盤規劃

55. 55
接手後端開發並重構 - 實作
●
MongoDB schema 偏亂
– schema 一開始沒有通盤規劃
– RDBMS 無法套用在 NoSQL 上

56. 56
接手後端開發並重構 - 實作
●
MongoDB schema 偏亂
– schema 一開始沒有通盤規劃
– RDBMS 無法套用在 NoSQL 上
– 有 NoSQL 基礎，容易理解 schema 設計

57. 57
MongoDB schema 偏亂

58. 58
MongoDB schema 偏亂

59. 59
MongoDB schema 偏亂
測試資料夾裡面有許多景點

60. 60
MongoDB schema 偏亂 - RDBMS 的做法

61. 61
MongoDB schema 偏亂 - RDBMS 的做法

62. 62
MongoDB schema 偏亂 - RDBMS 的做法
POI collection

63. 63
MongoDB schema 偏亂 - RDBMS 的做法

64. 64
MongoDB schema 偏亂 - RDBMS 的做法

65. 65
MongoDB schema 偏亂 - RDBMS 的做法
POI folder collection

66. 66
MongoDB schema 偏亂 - NoSQL 的做法

67. 67
MongoDB schema 偏亂 - NoSQL 的做法

68. 68
MongoDB schema 偏亂 - NoSQL 的做法
要怎麼顯示，就怎麼存

69. 69
接手後端開發並重構 - 實作

70. 70
接手後端開發並重構 - 實作
●
API 沒有 RESTful

71. 71
接手後端開發並重構 - 實作
●
API 沒有 RESTful
– API 全部都是 POST /actionName

72. 72
接手後端開發並重構 - 實作
●
API 沒有 RESTful
– API 全部都是 POST /actionName
– 資料塞在 Request body

73. 73
接手後端開發並重構 - 實作
●
API 沒有 RESTful
– API 全部都是 POST /actionName
– 資料塞在 Request body
●
持續正規化 body 、 header

74. 74
接手後端開發並重構 - 實作
●
API 沒有 RESTful
– API 全部都是 POST /actionName
– 資料塞在 Request body
●
持續正規化 body 、 header 沒有 HTTP cache

75. 75
API 沒有 RESTful

76. 76
API 沒有 RESTful

77. 77
API 沒有 RESTful
parseMemberObjectId, token 要統一放到 header

78. 78
接手後端開發並重構 - 實作

79. 79
接手後端開發並重構 - 實作
●
擴展 Express.js 函式

80. 80
接手後端開發並重構 - 實作
●
擴展 Express.js 函式
– req.funliday

81. 81
接手後端開發並重構 - 實作
●
擴展 Express.js 函式
– req.funliday
– res.success

82. 82
擴展 Express.js 函式 - req.funliday

83. 83
擴展 Express.js 函式 - req.funliday

84. 84
擴展 Express.js 函式 - req.funliday
自訂 header 放到 x-funliday 裡面

85. 85
擴展 Express.js 函式 - req.funliday

86. 86
擴展 Express.js 函式 - req.funliday

87. 87
擴展 Express.js 函式 - req.funliday
取出 x-funliday-header

88. 88
擴展 Express.js 函式 - req.funliday

89. 89
擴展 Express.js 函式 - req.funliday

90. 90
擴展 Express.js 函式 - req.funliday
與 semver 實際運用

91. 91
擴展 Express.js 函式 - res.success

92. 92
擴展 Express.js 函式 - res.success

93. 93
擴展 Express.js 函式 - res.success
可支援 object 以及 array

94. 94
擴展 Express.js 函式 - res.success

95. 95
擴展 Express.js 函式 - res.success

96. 96
擴展 Express.js 函式 - res.success
資料庫多回傳一筆資料，可以判斷是否還有下一頁

97. 97
接手後端開發並重構

98. 98
接手後端開發並重構
( 有 team 的話 ...)

99. 99
有 team 的話 ...
●
MongoDB schema 偏亂： 1
●
API 沒有 RESTful+ 擴展 Express.js 函式： 1

100. 100
老大哥正在看著你

101. 101
老大哥正在看著你
( 一條龍 )

102. 102
老大哥正在看著你 - 背景 (2019/9)

103. 103
老大哥正在看著你 - 背景 (2019/9)
●
為了記錄 log

104. 104
老大哥正在看著你 - 背景 (2019/9)
●
為了記錄 log
●
機器一直死

105. 105
老大哥正在看著你 - 團隊 (1*4)
●
iOS 、 Web 、找錢、會計： 1
●
Android ： 1
●
Design ： 1
●
Backend ： 1 團隊沒有變化，還在找 Web

106. 106
老大哥正在看著你 - 實作

107. 107
老大哥正在看著你 - 實作
●
加上 log

108. 108
老大哥正在看著你 - 實作
●
加上 log
– 原本使用 heroku 合作的 papertrail

109. 109
老大哥正在看著你 - 實作
●
加上 log
– 原本使用 heroku 合作的 papertrail
– 因為有裝 Elasticsearch ，所以整合進 ELK stack

110. 110
老大哥正在看著你 - 實作
●
加上 log
– 原本使用 heroku 合作的 papertrail
– 因為有裝 Elasticsearch ，所以整合進 ELK stack
一開始為了省事，之後為了省錢

111. 111
老大哥正在看著你 - 實作

112. 112
老大哥正在看著你 - 實作
●
加上 APM

113. 113
老大哥正在看著你 - 實作
●
加上 APM
– Application Performance Monitoring

114. 114
老大哥正在看著你 - 實作
●
加上 APM
– Application Performance Monitoring
– 也是使用 heroku 合作的 New Relic

115. 115
老大哥正在看著你 - 實作
●
加上 APM
– Application Performance Monitoring
– 也是使用 heroku 合作的 New Relic
– 原本要改用 Elastic APM ，但安裝失敗

116. 116
老大哥正在看著你 - 實作
●
加上 APM
– Application Performance Monitoring
– 也是使用 heroku 合作的 New Relic
– 原本要改用 Elastic APM ，但安裝失敗
一開始為了省事，之後為了省錢

117. 117
老大哥正在看著你 - 實作

118. 118
老大哥正在看著你 - 實作
●
加上 status page

119. 119
老大哥正在看著你 - 實作
●
加上 status page
– 避免被動得知系統發生錯誤

120. 120
老大哥正在看著你 - 實作
●
加上 status page
– 避免被動得知系統發生錯誤
– 直到 2023/6 才加上去

121. 121
老大哥正在看著你 - 實作
●
加上 status page
– 避免被動得知系統發生錯誤
– 直到 2023/6 才加上去
– 使用 Uptime Kuma

122. 122
加上 status page

123. 123
加上 status page

124. 124
老大哥正在看著你

125. 125
老大哥正在看著你
( 有 team 的話 ...)

126. 126
有 team 的話 ...

127. 127
有 team 的話 ...
●
全部交給 SRE ！

128. 128
持續加入各種功能

129. 129
持續加入各種功能
( 一條龍 )

130. 130
持續加入各種功能 - 背景 (2019/6)

131. 131
持續加入各種功能 - 背景 (2019/6)
●
Funliday 不可能只有景點跟行程

132. 132
持續加入各種功能 - 背景 (2019/6)
●
Funliday 不可能只有景點跟行程
●
開始讓使用者寫遊記 (2014 就有的想法 )

133. 133
持續加入各種功能 - 背景 (2019/6)
●
Funliday 不可能只有景點跟行程
●
開始讓使用者寫遊記 (2014 就有的想法 )
●
這時，還沒想到如何賺錢

134. 134
持續加入各種功能 - 團隊 (1*5)
●
iOS 、找錢、會計： 1
●
Web ： 1
●
Android ： 1
●
Design ： 1
●
Backend ： 1
新功能上線，需要 Web 實作

135. 135
持續加入各種功能 - 實作

136. 136
持續加入各種功能 - 實作
●
寫遊記

137. 137
持續加入各種功能 - 實作
●
寫遊記
– 上傳圖片： S3+CloudFront

138. 138
持續加入各種功能 - 實作
●
寫遊記
– 上傳圖片： S3+CloudFront
– 縮圖功能

139. 139
持續加入各種功能 - 實作
●
寫遊記
– 上傳圖片： S3+CloudFront
– 縮圖功能
●
第一版使用 Lambda (Python+thumbor)

140. 140
持續加入各種功能 - 實作
●
寫遊記
– 上傳圖片： S3+CloudFront
– 縮圖功能
●
第一版使用 Lambda (Python+thumbor)
●
第二版自製 image service (Node.js+sharp)

141. 141
持續加入各種功能 - 實作
●
寫遊記
– 上傳圖片： S3+CloudFront
– 縮圖功能
●
第一版使用 Lambda (Python+thumbor)
●
第二版自製 image service (Node.js+sharp)
●
第三版新增 Blurhash

142. 142
第一版使用 Lambda

143. 143
第一版使用 Lambda
●
AWS labs 的解決方案 serverless-image-handler

144. 144
第一版使用 Lambda
●
AWS labs 的解決方案 serverless-image-handler
●
payload 最大 6MB

145. 145
第一版使用 Lambda
●
AWS labs 的解決方案 serverless-image-handler
●
payload 最大 6MB
●
但沒人會寫 python ，無法維護

146. 146
第三版新增 Blurhash

147. 147
第三版新增 Blurhash

148. 148
第三版新增 Blurhash

149. 149
第三版新增 Blurhash

150. 150
第三版新增 Blurhash
qeFsDNIo8_x]%2WARiWXpf%MngkXRkj[jYt7?
wWVj]flV@ogt7V@bxt7t8ofV@kWWBj[ozkCxva
dWDogjYWBt8j[a~jZofoMRjoz

151. 151
第三版新增 Blurhash
qeFsDNIo8_x]%2WARiWXpf%MngkXRkj[jYt7?
wWVj]flV@ogt7V@bxt7t8ofV@kWWBj[ozkCxva
dWDogjYWBt8j[a~jZofoMRjoz
資料量小，與其他解決方案比會少一次 request

152. 152
持續加入各種功能 - 實作

153. 153
持續加入各種功能 - 實作
●
定義資料結構一致的列表

154. 154
持續加入各種功能 - 實作
●
定義資料結構一致的列表
– 至少要跟設計師討論

155. 155
持續加入各種功能 - 實作
●
定義資料結構一致的列表
– 至少要跟設計師討論
– 統一遊記、行程、使用者、景點、商品列表

156. 156
定義資料結構一致的列表

157. 157
定義資料結構一致的列表

158. 158
定義資料結構一致的列表

159. 159
定義資料結構一致的列表

160. 160
定義資料結構一致的列表
封面 + 標題 + 座標

161. 161
定義資料結構一致的列表

162. 162
定義資料結構一致的列表

163. 163
定義資料結構一致的列表

164. 164
定義資料結構一致的列表
用 type 決定顯示的方式，用 action 決定點擊的行為

165. 165
持續加入各種功能

166. 166
持續加入各種功能
( 有 team 的話 ...)

167. 167
有 team 的話 ...
●
寫遊記： 2
●
定義資料結構一致的列表： 1

168. 168
總算想到 SEO

169. 169
總算想到 SEO
( 一條龍 )

170. 170
總算想到 SEO - 背景 (2019/10)

171. 171
總算想到 SEO - 背景 (2019/10)
●
Funliday 一開始只有 App

172. 172
總算想到 SEO - 背景 (2019/10)
●
Funliday 一開始只有 App
●
要分享給一般使用者，做了 Web

173. 173
總算想到 SEO - 背景 (2019/10)
●
Funliday 一開始只有 App
●
要分享給一般使用者，做了 Web
●
Web 開發使用 React

174. 174
總算想到 SEO - 背景 (2019/10)
●
Funliday 一開始只有 App
●
要分享給一般使用者，做了 Web
●
Web 開發使用 React
●
沒有使用 create-react-app

175. 175
總算想到 SEO - 背景 (2019/10)
●
Funliday 一開始只有 App
●
要分享給一般使用者，做了 Web
●
Web 開發使用 React
●
沒有使用 create-react-app
●
開發模式為前後端分離

176. 176
總算想到 SEO - 團隊 (1*5)
●
iOS 、找錢、會計： 1
●
Web ： 1
●
Android ： 1
●
Design 、找錢： 1
●
Backend ： 1
黑暗時期，連設計也要出來找錢

177. 177
API 取得 metadata

178. 178
API 取得 metadata

179. 179
API 取得 metadata

180. 180
API 取得 metadata
前後端分離的極致，很奇怪的模式

181. 181
自建 prerender

182. 182
自建 prerender

183. 183
自建 prerender
自己用 puppeteer 開發的 prerender

184. 184
自建 prerender

185. 185
自建 prerender

186. 186
自建 prerender
透過 Nginx 轉導 crawler 到 prerender

187. 187
重要 route 改從 DB

188. 188
重要 route 改從 DB

189. 189
重要 route 改從 DB

190. 190
重要 route 改從 DB
開始朝向 SSR 前進

191. 191
新 route 改成 SSR

192. 192
新 route 改成 SSR

193. 193
新 route 改成 SSR
純 SSR ，需要不排斥寫後端的前端人

194. 194
總算想到 SEO

195. 195
總算想到 SEO
( 有 team 的話 ...)

196. 196
有 team 的話 ...
●
重要 route 改從 DB ： 2
●
新 route 改成 SSR ： 2

197. 197
開始導入電商

198. 198
開始導入電商
( 一條龍 )

199. 199
開始導入電商 - 背景 (2020/9)

200. 200
開始導入電商 - 背景 (2020/9)
●
COVID-19 無法出國，報復式國旅

201. 201
開始導入電商 - 背景 (2020/9)
●
COVID-19 無法出國，報復式國旅
●
除了流量，也要開始注意營收

202. 202
開始導入電商 - 名詞解釋：分銷

203. 203
開始導入電商 - 名詞解釋：分銷
●
在 Funliday 找商品

204. 204
開始導入電商 - 名詞解釋：分銷
●
在 Funliday 找商品
●
在 Funliday 看商品細節

205. 205
開始導入電商 - 名詞解釋：分銷
●
在 Funliday 找商品
●
在 Funliday 看商品細節
●
在 Funliday 結帳

206. 206
開始導入電商 - 名詞解釋：分銷
●
在 Funliday 找商品
●
在 Funliday 看商品細節
●
在 Funliday 結帳
●
利潤高

207. 207
開始導入電商 - 名詞解釋：分銷
●
在 Funliday 找商品
●
在 Funliday 看商品細節
●
在 Funliday 結帳
●
利潤高
●
各種意義上的開發成本高

208. 208
開始導入電商 - 團隊 (1*6)
●
iOS 、找錢、會計： 1
●
Web ： 1
●
Android ： 1
●
Design 、找錢、營運： 1
●
Business Development ： 1 ( 日本人 )
●
Backend ： 1
設計開始扛營運
有了一位日本 BD

209. 209
開始導入電商 - 分銷實作

210. 210
開始導入電商 - 分銷實作
●
一個行程：很多景點組成

211. 211
開始導入電商 - 分銷實作
●
一個行程：很多景點組成
●
一個遊記：一個行程 + 很多圖片

212. 212
開始導入電商 - 分銷實作
●
一個行程：很多景點組成
●
一個遊記：一個行程 + 很多圖片
●
一個商品：一個遊記 + 可販賣

213. 213
開始導入電商 - 分銷實作困難點

214. 214
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)

215. 215
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)
– 避免超賣

216. 216
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)
– 避免超賣
●
租車金額試算 (estimate)

217. 217
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)
– 避免超賣
●
租車金額試算 (estimate)
– 各家供應商算法不同

218. 218
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)
– 避免超賣
●
租車金額試算 (estimate)
– 各家供應商算法不同
– 平日假日算法不同

219. 219
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)
– 避免超賣
●
租車金額試算 (estimate)
– 各家供應商算法不同
– 平日假日算法不同
– 連假算法不同

220. 220
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)
– 避免超賣
●
租車金額試算 (estimate)
– 各家供應商算法不同
– 平日假日算法不同
– 連假算法不同
– 連續租 n 日算法不同

221. 221
開始導入電商 - 分銷實作困難點
●
資料庫交易 (transaction)
– 避免超賣
●
租車金額試算 (estimate)
– 各家供應商算法不同
– 平日假日算法不同
– 連假算法不同
– 連續租 n 日算法不同
– ... 等

222. 222
開始導入電商 - 分銷營運困難點

223. 223
開始導入電商 - 分銷營運困難點
●
客服成本超高

224. 224
開始導入電商 - 分銷營運困難點
●
客服成本超高
– 人工出票

225. 225
開始導入電商 - 分銷營運困難點
●
客服成本超高
– 人工出票
– 所有商品的 FAQ 都要完全了解

226. 226
開始導入電商 - 分銷營運困難點
●
客服成本超高
– 人工出票
– 所有商品的 FAQ 都要完全了解
– ... 等

227. 227
開始導入電商 - 分銷營運困難點

228. 228
開始導入電商 - 分銷營運困難點

229. 229
開始導入電商 - 分銷營運困難點

230. 230
開始導入電商 - 分銷營運困難點

231. 231
開始導入電商 - 分銷營運困難點
●
但景點商家不知道

232. 232
開始導入電商 - 分銷營運困難點
●
但景點商家不知道
– QR code 不同

233. 233
開始導入電商 - 分銷營運困難點
●
但景點商家不知道
– QR code 不同
– 現場退票

234. 234
開始導入電商 - 分銷營運困難點
●
但景點商家不知道
– QR code 不同
– 現場退票
– ... 等

235. 235
開始導入電商 - 分銷營運困難點

236. 236
開始導入電商 - 分銷營運困難點
●
但 Funliday 不知道

237. 237
開始導入電商 - 分銷營運困難點
●
但 Funliday 不知道
– 供應商商品已下架

238. 238
開始導入電商 - 分銷營運困難點
●
但 Funliday 不知道
– 供應商商品已下架
– 供應商改價格

239. 239
開始導入電商 - 分銷營運困難點
●
但 Funliday 不知道
– 供應商商品已下架
– 供應商改價格
– ... 等

240. 240
開始導入電商 - 分銷營運困難點

241. 241
開始導入電商 - 分銷營運困難點
●
票券及一日遊有無限組合，上架困難，舉例：

242. 242
開始導入電商 - 分銷營運困難點
●
票券及一日遊有無限組合，上架困難，舉例：
– 平日 299 元、假日 399 元

243. 243
開始導入電商 - 分銷營運困難點
●
票券及一日遊有無限組合，上架困難，舉例：
– 平日 299 元、假日 399 元
– 大人票 299 元、小孩票 199 元

244. 244
開始導入電商 - 分銷營運困難點
●
票券及一日遊有無限組合，上架困難，舉例：
– 平日 299 元、假日 399 元
– 大人票 299 元、小孩票 199 元
– 一個小孩一定要配一個大人

245. 245
開始導入電商 - 分銷營運困難點
●
票券及一日遊有無限組合，上架困難，舉例：
– 平日 299 元、假日 399 元
– 大人票 299 元、小孩票 199 元
– 一個小孩一定要配一個大人
– 七八月第一週假日特價 99 元

246. 246
開始導入電商 - 分銷營運困難點
●
票券及一日遊有無限組合，上架困難，舉例：
– 平日 299 元、假日 399 元
– 大人票 299 元、小孩票 199 元
– 一個小孩一定要配一個大人
– 七八月第一週假日特價 99 元
– ... 等

247. 247
開始導入電商 - 分銷營運困難點

248. 248
開始導入電商 - 分銷營運困難點

249. 249
開始導入電商 - 分銷營運困難點

250. 250
開始導入電商 - 分銷營運困難點

251. 251
開始導入電商 - 分銷營運困難點

252. 252
開始導入電商 - 分銷營運困難點
●
業務開發困難

253. 253
開始導入電商 - 分銷營運困難點
●
業務開發困難
– 店家主動聯絡希望上架他們商品，但利潤低

254. 254
開始導入電商 - 分銷營運困難點
●
業務開發困難
– 店家主動聯絡希望上架他們商品，但利潤低
– 店家都已在雙 K 上架，不想在 Funliday 上架

255. 255
開始導入電商 - 分銷營運困難點
●
業務開發困難
– 店家主動聯絡希望上架他們商品，但利潤低
– 店家都已在雙 K 上架，不想在 Funliday 上架
– 沒有專職台灣業務開發夥伴

256. 256
開始導入電商 - 分銷營運困難點
●
業務開發困難
– 店家主動聯絡希望上架他們商品，但利潤低
– 店家都已在雙 K 上架，不想在 Funliday 上架
– 沒有專職台灣業務開發夥伴
– ... 等

257. 257
開始導入電商

258. 258
開始導入電商
( 有 team 的話 ...)

259. 259
有 team 的話 ...
●
專門客服： 2
●
業務開發： 2

260. 260
導購真香

261. 261
導購真香 - 名詞解釋

262. 262
導購真香 - 名詞解釋
●
在 Funliday 找商品

263. 263
導購真香 - 名詞解釋
●
在 Funliday 找商品
●
在 OTA 看商品細節

264. 264
導購真香 - 名詞解釋
●
在 Funliday 找商品
●
在 OTA 看商品細節
●
在 OTA 結帳

265. 265
導購真香 - 名詞解釋
●
在 Funliday 找商品
●
在 OTA 看商品細節
●
在 OTA 結帳
●
利潤低

266. 266
導購真香 - 名詞解釋
●
在 Funliday 找商品
●
在 OTA 看商品細節
●
在 OTA 結帳
●
利潤低
●
各種意義上的開發成本低

267. 267
導購真香 - 名詞解釋
●
在 Funliday 找商品
●
在 OTA 看商品細節
●
在 OTA 結帳
●
利潤低
●
各種意義上的開發成本低
●
客服成本超低

268. 268
導購真香 - 名詞解釋
●
在 Funliday 找商品
●
在 OTA 看商品細節
●
在 OTA 結帳
●
利潤低
●
各種意義上的開發成本低
●
客服成本超低
Online Travel Agency ：線上旅行社

269. 269
導購真香 - 背景 (2023/6)

270. 270
導購真香 - 背景 (2023/6)
●
分銷太困難，引進導購合作

271. 271
導購真香 - 背景 (2023/6)
●
分銷太困難，引進導購合作
●
供應商先搞定雙 K 就好

272. 272
導購真香 - 背景 (2023/6)
●
分銷太困難，引進導購合作
●
供應商先搞定雙 K 就好
●
現有系統可直接支援

273. 273
導購真香 - 團隊 (1*8)
●
iOS 、找錢、會計： 1
●
Web ： 1( 香港人 )
●
Android ： 1
●
Design 、營運： 1
●
Business Development ： 1 ( 日本人 )
●
Marketing ： 1
●
Backend ： 2
設計可以專心在營運上面
團隊愈來愈多元
多了一位行銷和後端

274. 274
導購真香 - 實作

275. 275
導購真香 - 實作
●
後端不需太多調整

276. 276
導購真香 - 實作
●
後端不需太多調整
●
前端有依照原規格實作，少許調整就可上線

277. 277
導購真香 - 實作

278. 278
導購真香 - 實作

279. 279
導購真香 - 實作
導購轉址頁

280. 280
導購真香 - 實作

281. 281
導購真香 - 實作

282. 282
回顧一下

283. 283
回顧一下

284. 284
回顧一下

285. 285
Conclusion

286. 286
永遠迎接更多的困難

287. 287
永遠迎接更多的困難
●
前端開發很奔放

288. 288
永遠迎接更多的困難
●
前端開發很奔放
– 為了前端孤兒，後端要支援舊前端

289. 289
永遠迎接更多的困難
●
前端開發很奔放
– 為了前端孤兒，後端要支援舊前端
●
新創資深工程師的 context switch 要夠快速

290. 290
永遠迎接更多的困難
●
前端開發很奔放
– 為了前端孤兒，後端要支援舊前端
●
新創資深工程師的 context switch 要夠快速
– 許多 knowhow 都放在腦子裡

291. 291
永遠迎接更多的困難
●
前端開發很奔放
– 為了前端孤兒，後端要支援舊前端
●
新創資深工程師的 context switch 要夠快速
– 許多 knowhow 都放在腦子裡
●
創業最缺的就是時間

292. 292
永遠迎接更多的困難
●
前端開發很奔放
– 為了前端孤兒，後端要支援舊前端
●
新創資深工程師的 context switch 要夠快速
– 許多 knowhow 都放在腦子裡
●
創業最缺的就是時間
– 可以用錢解決的就不要花時間研究

293. 293
ONE MORETHING

294. 294

295. 295

296. 296
References
●
Funliday Tech Blog
●
Slideshare by kewang

297. 297