大多数钱包卡券项目还停留在”注册时发一次卡”的老套路上:用户注册,系统发卡,然后就指望对方哪天想起来自己钱包里躺着一张优惠券。等他真的走进你的海外门店时,这张卡早已经被埋在一个他好几周没打开过的钱包 App 里,翻三屏都未必找得到。
更聪明的做法是把触发时机倒过来:用户一进入门店范围,卡券当场发放,直接躺在锁屏上——这时候,买不买还是一个悬而未决的问题。
这一整套流程,在 Pushwoosh 里只是一条 Customer Journey:geozone 进入事件触发,一张写好优惠的 Apple 或 Google Wallet 卡券当场发放,再由一条推送把领取链接送到用户所在的平台上。
为什么用位置触发,而不是注册表单
在注册环节发放的钱包卡券,要跟一堆其他引导步骤抢用户的注意力:权限弹窗、资料填写、一个没人看完的产品导览。大多数用户在卡券被真正添加之前,标签页就已经关掉了。
而 由 geozone 进入触发的卡券 直接跳过了这场竞争。用户和卡券之间没有表单挡着,优惠对应的是他决定要不要买的那 5 分钟,而不是他几周前注册时随便的哪种心情。
如何搭建一条地理围栏钱包卡券旅程
在上线一条地理触发的钱包卡券旅程之前,你需要准备好 2 样东西:一个已经连接 Apple 和/或 Google 的钱包卡券模板,以及一个围绕你的门店画好的 geozone cluster。两样都备齐后,4 步就能把这条旅程搭起来。
-
Geozone 进入
设备进入 cluster 中的任意一个区域,触发进入事件(如
PW_GeozoneEntered)。这就是旅程的入口,不需要额外建名单或排期一场活动。 -
发放钱包卡券
旅程当场从你的模板发放一张 Apple 或 Google Wallet 卡券。设置活动时,在某个字段里填上一个实时优惠(比如一个折扣百分比),这次运行发放的每一张卡都会带着它。用户还没做任何决定,卡就已经在他设备上了。
-
按平台分支
一个过滤器判断设备是 iOS 还是 Android,并分别路由。Apple 和 Google 的卡券在底层是两种不同的对象,所以后面那条推送必须指向正确的那一个。
-
发送卡券链接
每条分支各发一条推送,直接从刚发放的卡券里取出卡券链接和序列号,按平台做个性化。用户点一下,卡就进了他的钱包。
地理围栏钱包卡券最适合谁
最佳场景: 出海零售、生鲜/商超,以及跨境电商的海外线下门店、快闪店和取货点——任何一种”用户的物理位置本身就是购买信号”的业务。“人在门店附近”和”优惠已经到手”之间的链路越短,转化效果越好。对没有实体位置可以画围栏的 App,这套打法天然不适用。
如果你正好是这类业务,有几点要留意:
- 半径要选对。 和其他地理活动一样:围栏画太大,“门店附近”就失去意义了。发卡步骤会给同一台设备去重,但每天都会路过的老客户,依然会反复进出同一个区域。简单的解法是在 geozone 或 cluster 上设置冷却时间(而不是在发卡步骤上),控制这个流程被触发的频率。
- 对没装你 App 的人照样有效。 因为卡券活在 Apple Wallet 或 Google Wallet 里,而不是 App 内部,所以哪怕对方很少打开 App,优惠依然生效。你还可以把同一张卡通过链接或二维码分发出去,触达那些从未安装过你 App 的顾客——这对双十一、黑五这类大促期间的海外快闪活动尤其有用。
- 量清楚到底是什么在拉动用户。 跟踪卡券保存量和到店核销量,看清楚到底是哪些门店、哪些优惠真正带来了到访。
用 Pushwoosh 上线地理围栏钱包卡券
如果推送、邮件或应用内消息已经在你的账户里跑起来了,这些都不算新接入。geozone、钱包卡券,以及按平台分支的推送,和其他一切一样,都画在同一块 用户旅程编排工具 画布上,瞄准同样的 User ID 和同样的分群。整套链路跑在你现有的 FCM/APNs 海外推送基础设施上,数据处理符合 GDPR 要求、由欧盟和美国数据中心承载,不涉及国内推送通道。
