设计用户真正使用的礼品功能：基于 58 款应用的证据
2025 年假日购物季，美国消费者在礼品卡上的支出约为 290 亿美元，其中 43% 的人至少买过一张。据全美零售联合会（National Retail Federation）的调查，礼品卡高居人们“最想要的礼物”榜首。
这些数字解释了公司为什么要备货礼品卡，但它们并没有告诉我们：产品应该在什么时候引导用户送出礼物，才能获得最好的效果。本文将探讨送礼功能是否值得做进你的应用。为了回答这个问题，我调研了 Mobbin 参考库中的 58 款应用。
这里的“送礼”涵盖很广：礼品卡、赠送订阅、直播打赏，或结算时的加购项，都算在内。这 58 款应用中，有 49 款带有用户可以从头走到尾的送礼流程，触发方式多达 9 种。
举例来说，Etsy 会保存购物车内容，Duolingo 会在界面上直接显示好友的课程进度，Blinkit 则把节日纳入了营销日历。每款产品都清楚用户在什么时候可能想送出礼物。
下文将逐一介绍这 9 个触发时机，包括各自的开发成本，以及在开发动手之前需要设计好的界面。
前置知识
阅读本文，你最好具备：
一定的消费类产品设计或研究经验，熟悉入口、流失、转化这些日常概念。
对获客经济学的基本了解，包括获客成本（CAC）、激活，以及为什么推荐激励的定价逻辑不同于追加销售。
能看懂
CREATE TABLE语句的 SQL 基础。你不需要亲手写，用到 SQL 的两节会明确标出；即使跳过，设计方面的结论也完全独立成立。
目录
九类场景中有八类存在明确触发点
以下是 58 款应用的分布情况（部分应用横跨多行）。例如，仅 Uber Eats 一家就覆盖了上述五种场景。
| 场景 | 应用数 | 触发条件 |
|---|---|---|
| 结账加购 | 12 | 购物车已装满且用户已输入卡片信息 |
| 资金包装 | 4 | 转账时，纯数字显得过于冷冰冰 |
| 节日目录 | 19 | 日历上的节日或生日 |
| 平台发放礼物 | 5 | 公司希望用户重复执行的动作 |
| 拟赠型推荐 | 7 | 刚刚完成一次顺利体验之后 |
| 共享进度 | 2 | 目标可见且双方进度明显失衡的共同目标 |
| 即时社交货币 | 10 | 正在发生的实时互动 |
| 预存价值（即礼品卡） | 22 | 用户需主动寻找 |
| 订阅激励 | 9 | 成为满意的老订阅用户 |
推荐奖励支付的是发起者引荐新用户的费用，而平台发放的礼物则是公司颁给自家用户的奖品。因此，在这两类场景中，资金和接收方在本质上已归属公司，如下方图表所示。
礼品卡在数量上遥遥领先。在列表中，它也是唯一不需要任何触发的场景，因为赠送的意愿必须在使用应用之前就已经产生。
列表上的其他所有场景，目的都是在赠送者想到之前提供这个理由。如果只开发礼品卡功能并止步于此，需求侧也会被随之切断。
这种区别对团队决定构建什么功能至关重要。礼品卡是购买对象，而非购买理由。因此，只开发礼品卡并止步于此的团队，构建的是礼品交易的供给侧而非需求侧，该功能只能躺在账户菜单里，等待那些已经打算使用它的用户。
其余八种场景旨在制造这种意愿，每种都将请求绑定到产品可以检测到的特定时刻。
每种场景都将触发点与强化手段配对
以下每个条目都阐明了启动场景的触发点，以及如何从第一次赠送转化为第二次赠送。
储值功能（22 个应用）
赠送者选择金额、挑选卡片设计、填写“致”和“自”、撰写留言并结账。22 个应用都采用了相同的流程。这是研究中常见的礼品功能，所需的设计工作量也是最小的。
触发点：赠送者通过打开菜单并主动寻找才能到达礼品卡，因此赠送意愿先于应用出现。其他八种场景则旨在主动提供这种意愿。
强化手段：Blank Street、Airbnb 和 Blue Apron 允许赠送者预约送达时间，使其能在想起时立即操作，而非等到当天；Urban Outfitters 将预订窗口限制在 90 天内。预览功能让赠送者确切知道接收者将看到什么。随后，Blank Street 在购买确认页面上加了一个贪吃蛇街机游戏，奖品是一杯免费咖啡。
使用者：Uber、Uber Eats、Starbucks、sweetgreen、DoorDash、Shopee、SHEIN、Blank Street、App Store、Shipt、Blinkit、Zip、HelloFresh、Blue Apron、Airbnb、Urban Outfitters、Base44、Satispay、Walmart、Amazon、Everyday Rewards、Lovi。
19 款应用：按场合组织的礼品目录
有 19 款应用按场合来陈列礼品目录，这让「日历」成为八种触发机制中使用最广的一种。顶部的标签页负责引导用户。
送礼者点进这个页面时往往没想好要庆祝什么，标签页便顺势提供了一个。Starbucks 排列着父亲节、毕业季、生日和感谢，而 Walmart 还加了一个「Just Because（只因想送）」标签，专门覆盖那些算不上节日的日子。
地域性节日更重要。Blinkit 和 Zomato 主打兄妹节（Rakshabandhan），GoPay 主打开斋节和 THR，Shopee 主打毕业贺礼（Selamat Wisuda），而只针对美国节日的场合设置根本覆盖不到这些买家。
触发机制：日历提供了一个送礼者本来就觉得「不得不送」的日子。
强化设计：场合把贺卡图案和文案打包一起给出，送礼者完全不用自己写祝福。GoPay 先给一个主题红包封套，再来一条名人语音，最后附上一句类似「别长大，长大是个坑」的现成祝福语。
使用者：Uber、Uber Eats、Postmates、Starbucks、sweetgreen、Walmart、Amazon、Shopee、Grab、Blinkit、Zomato、Ulta Beauty、SKIMS、GoPay、Letterboxd、Nike、Shipt、Target、Faire。
12 款应用：结账时的加购推荐
12 款应用在购物车里、发货与支付之间塞入一个开关。Etsy 和 Instacart 用切换开关，Ulta Beauty 和 Yami 弹出一个面板，DoorDash 和 Uber Eats 则把它提升为结账列表中的一行。这个请求只需一次点击。
触发机制：用户已经掏出卡片准备付款了，多加一个请求几乎零成本。
强化反馈：Ulta 对礼品袋收取 3.99 美元，Blinkit 收取 30 卢比，而礼品留言本身免费。Lululemon 承诺打印在收据上的礼品留言会隐藏价格，直接缓解了购物者入场时可能有的焦虑。Apple Store 则会询问是展示礼品还是保留惊喜。
适用品牌：Etsy、Instacart、Yami、Ulta Beauty、lululemon、Apple Store、Best Buy、DoorDash、Uber Eats、Blinkit、Natural AI、Blank Street。
10款应用中的社交货币实时时刻
十款应用将礼品功能嵌入实时互动中，并使用专属货币定价。Telegram 销售一种名为 Stars 的货币，其礼品会伴随彩带出现在聊天线程中。
由于该线程有观众，礼品购买的是可见度而非单纯的好感。
约会应用已经精确定价了这种价值。Hinge 上的玫瑰和 Coffee Meets Bagel 上的花朵都承诺让发送者立即显现，正如后者按钮上所言。Telegram 随后添加了使这一切在社交空间可行的控制选项。
“隐藏我的名字”允许发送者对除收件人外的所有人隐匿身份。Twitch 也提供相同的“匿名赠送”选项。
触发点：发送者希望在实时线程中压过其他争夺注意力的竞争者。
强化反馈：观众目睹礼品到达，Telegram 用稀缺性标记和分层阶梯为该时刻定价。100 Stars 售价 2.90 美元，35,000 Stars 售价 1,048 美元。摊算下来，七个档位每百个的价格在 2.88 到 2.99 美元之间，因此阶梯销售的是数字规模而非折扣。
在 Twitch 上，赠送订阅的单价随档位增加而下降：前五份为 SGD 6.99，第五份之后降至 SGD 4.99 并保持不变，但页面上的“划线价节省”提示始终显眼。负责审核这些徽章的设计师，应当先计算每个档位的单均价格。
使用此功能的平台： Telegram、Discord、Instagram、TikTok、Twitch、Azar、Binance、Badoo、Hinge、Coffee Meets Bagel。
9 款应用的订阅引流机制
有 9 款应用允许现有订阅者为非订阅者购买试用，这实质上是披着礼品外衣的获客渠道。诚实地做法会直接在界面上点明这一性质，例如 Thrive Market 直接用美元标明价值。
触发条件：订阅者留存足够久，从而愿意推荐产品。Discord、Telegram 和 Headway 将入口设置在设置页、付费墙或接收者资料页。
强化机制：Thrive Market 向赠送者提供 30 美元店铺积分，这是公司认定比替代方案更具性价比的获客成本。
Lovi 则完全绕开现金奖励，改为在账户中注入 5 张礼卡，每张兑换 7 天无限访问权。
Telegram 按订阅时长给予 Premium 折扣，3 个月打九折，1 年打五五折，这意味着承诺周期越长，每月实际支付越少。礼物会自动续费，因为根据 Thrive Market 的条款，接收者每年纪念日需支付 59.95 美元，除非主动取消。
使用此功能的平台： Thrive Market、Discord、Instagram、Telegram、Headway、Lovi、Shipt、Blackbird、Twitch。
7 款应用将推荐包装为赠予
有 7 款应用在文案和图标设计上将“推荐”表述为“赠送”，使用礼物包装插画，并让动词“赠送”优先于“获取”出现。
DoorDash 的标语是“给 5 美元，得 1 美元”。Base44 将“发送礼品卡”直接放在“推荐好友”下方，同处一个账户菜单，表明团队视二者为同源功能。
触发时机：Peerspace 在预订确认成功的页面上展示推荐链接，也就是用户刚完成预订后的那几秒钟。
强化手段：Peerspace 同时展示奖励的双边收益，将推荐返现上限设为 $5,000，并预先提供可直接发送的 SMS 和邮件分享文案。
采用此模式的产品：DoorDash、Lugg、Peerspace、Superpower、Preply、Manus、Base44。
平台发放礼物的 5 个应用
这五个应用主动送给用户一份礼物，并自己制造送礼的由头。Grab 的 Mystery Rewards 承诺完成任务就有惊喜，然后播放一段拆礼物动画；Temu 则更直接，推消息告诉你“你有 8 份礼包待领取”。
触发时机：平台希望某个行为被反复执行，于是把奖励挂在这个行为上。
强化手段：Grab 以随机间隔发放奖励，用户只需花几秒钟看一段开箱动画，无需其他付出。未领取数量以角标形式呈现，到期倒计时则把好奇心转化为紧迫感。Finch 是本次研究中做法最特别也最温暖的一个：只告诉收礼人“守护者们希望你喜欢这份礼物”，点到为止。
采用此模式的产品：Grab、Shopee、Temu、Everyday Rewards、Finch。
金钱包装的 4 个应用
这四个应用把转账本身看作小事，把全部设计心思花在“包装”上。Binance 的 Red Packet 可以把随机金额通过口令或二维码分发给多个接收者；Revolut 则会安排红包在接收者当地早晨送达。转账本身只是一行记录。
触发时机：送礼人有特定场合要庆祝，而干巴巴的转账显得生硬冷淡。
强化手段：Binance 把整个领取过程做成了限时体验：红包可在首个人领取后 45 秒内过期，倒计时由发送者设定，未领完的金额三天后自动退款。Rewards Booster 还提供付费选项，可将口令曝光量最多提升 90%。GoPay 则在分享动作上加了抽奖机制，接收者每次领取都会掉落 Coins。
采用此模式的产品：GoPay、Binance、Revolut、Satispay。
共享进度型的 2 个应用
这两个应用让礼物具备实际功能而非仅是象征，这也是本次研究中最少见的场景。
Duolingo 的好友任务为两人设定共同目标，并并排展示各自贡献。例如，在三天内完成 15 课的剩余名额中，Sam 还没开始学习，而另一位学习者已完成 1 课。这种进度差异在任何人考虑赠送礼物之前就已直观呈现在界面上。头像下方设有 NUDGE 和 GIFT 两个按钮。
触发机制：Duolingo 展示正在进行的共享目标，让落后一方的进度一目了然。App 主动指出谁拖了后腿，无需学习者费力寻找助力的途径。
强化反馈：学习者消耗 XP 加速器推动任务进度。发送者在撰写留言时容易卡壳，Duolingo 自动代写文案。消耗的 20 颗宝石来自用真金白银购买的软货币，一旦耗尽便需充值，因此慷慨送礼驱动的购买行为与修复连续打卡记录的动机如出一辙。发送后按钮状态变为 SENT 并持续显示，让双方都能清晰感知这一行为。
Finch 在好友个人主页将“Send Gift”与“Share Goal”并列放置，价格为 200 颗彩虹石，功能列表至此结束。
适用对象：Duolingo、Finch。
九大场景中的六类共性痛点
无论团队选择哪种场景，发送流程中反复出现相同的六大问题。以下逐一阐述问题本质以及受调查 App 的应对策略。
1. 识别尚未注册的用户作为接收者。
发送者通常在填写接收者信息时受阻，因为目标用户尚未拥有账号。受调查 App 通常收集手机号或邮箱，并为两者皆无的情况提供通讯录选择功能；Grab 允许一次性添加最多 10 位接收者。面向陌生人的 App 采用最简标识符（只要该标识符能承载消息即可），将账号创建推迟到领取环节。
2. 在信息送达前获取从未授权的用户同意。
礼物会向与产品毫无关联的用户发送短信或邮件。Uber Eats 和 DoorDash 均要求发送者在接收者收到短信前确认已获得对方许可，将合规责任转移给唯一了解接收者情况的人。
3. 当发件人猜不出收件人想要什么时，如何选礼物。
猜不透，发件人就会中途放弃购买。Grab 和 Uber Eats 选择把决定权交给收件人，而非强行指定。Grab 提供多达三个选项供收件人挑选，Uber Eats 则提供“由收件人选择送达时间”和“取消时由收件人领取抵扣金”的选项。
4. 决定礼物要多么个性化。
仅有一个冷冰冰的金额显得缺乏心意，而每增加一层个性化都会多占用一个屏幕。个性化程度从卡片图案、手写留言，到 GoPay 的语音留言，再到 Uber Eats 和 Postmates 的录制视频不等。每一步都提升了发件人的投入感，也让通用金额显得更有价值。团队需选择与礼物价值相匹配的那个层级。
5. 决定礼物何时送达。
发件人往往在想起时立即行动，但这通常不是重要的日期。Revolut 安排在收件人的早晨送达，Apple Store 仅限于当天或指定日期，Urban Outfitters 则允许排期最长至 90 天后。排期功能让发件人可以顺从当下的冲动，同时确保礼物在特定日子送达。
6. 决定双方分别能看到什么。
这里涉及两个不同的秘密，应用在这两点上采取了不同策略。Uber、DoorDash、Uber Eats 和 Grab 会在支付前向发件人展示收件人的确切视图；Grab 将该界面命名为“最后确认”，以安抚那些购买自己从未体验过的情形的发件人。Apple Store 则对收件人隐藏具体内容，Telegram 的“隐藏我的姓名”和 Twitch 的“匿名赠送”则对收件人隐藏发件人。
发件人会按顺序遇到上述六个问题，本研究中的应用是这样解答的：
| # | 问题 | 应用的应对策略 |
|---|---|---|
| 1 | 收件人可能没有账户 | 使用电话号码或邮箱，在领取时创建账户 |
| 2 | 收件人从未订阅消息 | 发送前由发件人确认已获得许可 |
| 3 | 发件人猜不出对方想要什么 | 选择权移交给收件人，或缩减至两三个选项 |
| 4 | 仅有一个金额显得缺乏心意 | 在普通卡片基础上增加一层个性化，不宜更多 |
| 5 | 发件人行动早，日期在后面 | 支持定时送达，但设有送达时间窗口上限 |
| 6 | 礼物内容与赠送者身份分开保密 | 两个刻意的设计决策，外加给发送方预览收礼方视角 |
领取页：把一份礼物变成一个新客户
礼物通过短信、邮件或应用内消息里的链接送到收礼人手上，对方点开后会看到一个页面，展示朋友送了什么，并提供打开方式。设计师把这个页面叫做领取页。九种场景全部以它收尾，因为发送方的流程在付款处结束，而收礼方的流程从这里开始。
站在领取页前的人可能从没用过这款产品，而且手里还拿着朋友已经付过钱的东西。增长团队把这种模式称为礼物驱动获客：发送方承担了获客成本，而领取页决定公司能否真正拿下这个客户。
领取页上有两步必须按顺序走通。
第一步，收礼人要顺利打开礼物。中途放弃的人根本走不到注册环节。Meta Quest 要求输入二十五位兑换码，把一个陌生的链接变成一个有明确终点的任务；Binance、Finch 和 Shopee 则各自播放一段领取动画，让揭晓延迟一拍，给点击一个仪式感。应用会把这一步精确安排在收礼人可能关掉页面的位置。
然后产品提出注册账户的要求，正是这一步完成转化。Thrive Market 在自己的条款里写得直白：非会员收礼人必须先创建账户，礼物才会打开。Instagram 则让赠送的创作者订阅保持未激活状态，直到收礼人从收件箱里兑换——期间发送方的钱等于白花。收礼人用一个账户作为礼物“付款”，而且心甘情愿，因为值得要的东西已经在那里等着了。
设计团队如果将“领取页面”搁置，那么在流程启动之前就已经失去了用户。 Uber Eats 保留了“我的礼物”标签页，Satispay 将礼物区分为“已发送”和“已接收”，GoPay 则会显示未开启的礼物，并提示“剩余金额待领取”。这把一个未开启的礼物变成了促使发送者回访并追踪进度的理由，也让发送者有了查看状态的地方。研究中其他所有流程在支付完成后就抛下了发送者。五个设计决策变成工程难题
当一个人支付礼物而另一个人接收时，接收者可能还没有账号。礼物甚至可能在对方打开之前就已过期。 由此衍生出五个问题，尽早提出这些点可以避免后期的返工重建。
上图展示了礼物经历的九个状态，下方列出的五个问题分别对应其中某个状态转换。
第一行是大家通常设计的主路径：礼物以草稿形式开始，发送者填写表单；结账时变为待支付；在送达时刻前保持已排期；到达接收者时变为已送达；接收者打开时结束为已领取。只有接收者能完成最后这一步。
第二行涵盖其余所有情况，大部分设计工作也集中在此。银行卡拒付会让礼物进入支付失败状态；发送者改变主意会将其标记为已取消，被弃的草稿也会停在此处；领取窗口结束会导致状态变为已过期，随后自动转为已退款。这四个中有三个是终态，意味着礼物将永久停留于此，且这三个终态都会将钱退回给发送者。
1. 在两人拥有账号之前，礼物就需要双方身份
礼物包含两个身份，每个身份都带来独立的问题。发送方的身份不能直接从账户中读取。Uber Eats 要求填写发送方姓名，而非自动推断，因为付款人可能是代表家庭、团队或公司信用卡代购，礼品卡上的名字传递的是心意，而非账单记录。
接收方的身份可能根本不存在。Uber Eats、Thrive Market 和 Blank Street 均支持仅填写邮箱或手机号，这样系统才可在对方领取时自动创建账户。
第二个决策具有重大的商业影响。若强制要求用户注册账号才能发送礼品，该功能仅能触达现有客户，从而沦为留存工具而非获客手段。企业构建礼品功能旨在触达新用户，因此该要求消解了其核心价值。Thrive Market 和 Blank Street 允许接收方账号在领取前保持空白。
2. 同意记录需作为证据存储。
礼品功能会向未注册过任何服务的用户发送信息，在美国这受 TCPA 监管。DoorDash 要求发送方在发送短信前确认已获得接收方许可，勾选该复选框即满足合规要求。
若团队将该勾选动作仅存储为布尔值（true/false），两年后投诉到来时，公司需展示发送方当初同意了什么，但此时同意文案可能已修改过三四版。存储的 true 只能证明有人勾选过，却无法证明勾选时的文案内容。
两列数据可解决此问题：一列存储同意文案的版本标识符，另一列存储时间戳，且保留所有历史版本的文案。争议从“无据可查”变为“数据查询”。
3. 定时发送需适应时钟规则变更。
Revolut 承诺在接收方所在时区的早上八点送达。当伦敦的用户为悉尼的朋友设定生日礼品时，必须确保悉尼时间的承诺被履行，否则礼品会在前一天晚上送达。
政府通常仅提前数月调整时区规则，因此购买时锁定的时间戳在礼品到期时可能已不准确。Revolut 通过存储日期与时区，仅在调度器运行时解析为具体时刻，从而确保承诺生效。
4. 点击“领取”两次可能产生两次入账。
收款人点击后，网络慢导致页面上什么反应都没有，于是又点了一次。两次请求读到的是同一个礼物，都发现它还未被领取，于是都完成了支付。钱就这样划走了，而日志里没有报任何错误。
一个带条件的写入就能堵住这个漏洞——第二次请求会发现礼物已经被领取了。下一节会展开这一点。
5. 不同类型的礼物适用不同的过期规则。
Binance 把红包当作一种活跃气氛的玩法，四十五秒后即过期。而购买的礼品卡则是另一类法律意义上的对象。在美国，CARD Act 通常禁止储值在五年内过期，一些州的规定还要更严格。
如果四类礼物共用一个过期时长，这个功能就会变成合规隐患。每份礼物应有自己的过期时间，由其对象类型决定；「已过期」和「已退款」要分开存储，因为欠用户一笔退款和已经把钱退出去，是两回事。
一份礼物需要十七个字段来存储
上面五个决策最终都落在存储上，答案是设计一张十七列的表。这些列可以分为五组。
身份，六列，因为礼物有发送方和接收方，而接收方可能还不存在。
授权，两列，因为勾选框必须留作证据。
送达，两列，因为发送方的意图是一个日期加时区，而不是某个精确时刻。
过期与结果，三列，因为「已过期」「已领取」「已退款」是三种不同的状态。
金额与状态，四列，包括金额、币种、行的唯一标识，以及它在状态图中的位置。
研究中的四款应用多年前就定下了其中六列，然后不知不觉地把它们直接搬上了自己的界面。
| 界面展示的内容 | 背后隐含的字段 |
|---|---|
| Uber Eats：「这份礼物来自谁？」为必填项 | sender_name |
| Uber Eats：「接收方手机号」为必填项 | recipient_phone |
| Telegram：「隐藏我的名字」开关 | hide_sender |
| Thrive Market：条款规定非会员需创建账户才能兑换 | recipient_id，必须接受 null 值 |
| Duolingo：按钮状态从“赠送”变为“已送出” | status |
| Duolingo：礼物价格显示为二十个宝石而非美元 | currency，无法精简为三个字母 |
PostgreSQL 将上述 schema 写出如下。每个非显而易见的字段后都附有一行注释，标明其源自哪个应用，以便读者能对照上方的截图追溯每一行。跳读 SQL 部分的读者只会错过字段名，而不会遗漏核心逻辑。这十七个字段完整承载了整个功能。
CREATE TABLE gifts (
id uuid PRIMARY KEY,
status text NOT NULL, -- 上述九种状态之一
-- 双重身份标识。Uber Eats 要求发送者手动输入自己的名字，
-- 而不是从账户中自动推断。
sender_id uuid NOT NULL REFERENCES users(id),
sender_name text NOT NULL,
hide_sender boolean NOT NULL DEFAULT false, -- Telegram 提供此开关
-- 在领取前保持为空。Thrive Market、Blank Street 和 Uber Eats
-- 接受单独的邮箱或电话，之后再创建对方账户。
recipient_id uuid REFERENCES users(id),
recipient_email text,
recipient_phone text,
-- 以记录形式体现同意机制。DoorDash 在发送短信前确认用户已授权，
-- 且根据 TCPA 法规，证据在于用户同意的具体措辞版本。
consent_copy_version text,
consent_at timestamptz,
-- 表达送达意图而非即时执行。Revolut 承诺在收件人
-- 所在时区的 08:00 送达，且政府可能会调整时区规则。
deliver_on date NOT NULL,
deliver_tz text NOT NULL,
-- 过期时间因物品而异：币安红包仅 45 秒，
-- 而美国储值卡依据 CARD 法案至少有效五年。
expires_at timestamptz,
claimed_at timestamptz,
refunded_at timestamptz,
amount_minor bigint NOT NULL,
currency char(3) NOT NULL,
CONSTRAINT recipient_reachable CHECK (
recipient_id IS NOT NULL OR recipient_email IS NOT NULL
OR recipient_phone IS NOT NULL)
);
Thrive Market、Blank Street 和 Uber Eats 先收集地址，之后再建立账户。礼物可以存在数天，其所有者随后才出现，可空的 recipient_id 正是用来容纳这种时间差的；底部的检查约束则确保记录不会在所有方向上都无法触达收件人。
Revolut 曾承诺上午八点送达，而通过 deliver_on 配合 deliver_tz 的组合，能确保在收件人自己的时区兑现这一承诺——若只存一个冻结的时间戳，八点这个整点概念就彻底消失了。调度器只需一条查询即可找出当前应发放的礼品。
-- 按收件人而非服务器解析“现在到期”的礼品
SELECT id FROM gifts
WHERE status = 'scheduled'
AND (deliver_on + time '08:00') AT TIME ZONE deliver_tz <= now();
一个每几分钟运行一次的 worker，会在悉尼的早晨发放悉尼的礼品，九小时后再发放伦敦的那份，每份对应一行数据；当某国政府在购买与生日之间调整夏令时规则时，同一行数据在不同时刻会得出不同结果，而表本身无需改动。
“领取”这一动作本身就封装在一条语句里，WHERE 子句替代了团队原本打算上锁的方案。
UPDATE gifts
SET status = 'claimed', claimed_at = now(), recipient_id = $2
WHERE id = $1
AND status = 'delivered'
AND (expires_at IS NULL OR expires_at > now());
第二次点击执行同一条语句，发现该行状态已变为 claimed，返回影响行数为零，资金因此只划转一次。已过期的礼品同样返回零行。要区分这两种情况，只需多读一次 status 和 claimed_at。
领取页面只能展示该读取返回的内容。一个月后点开链接的收件人，看到的是说明而非白屏或“Error”——他会知道礼品在 3 月 12 日已被领取，或已过期、款项已退回给发送方。若产品当初没存 claimed_at，就只好回退到“出错了”并让用户去找客服。文案是设计师写的，但数据库结构决定了它能有多诚实。
如何为产品选对场景
虽然共有九种场景，但一个产品通常很少需要超过一种。下图统计了每种场景的开发成本，以页面数计。
在已测量的六种场景中，Money wrapping 成本最高，中位数是十二页，GoPay 为主题红包、明星语音祝福、推荐贺词和未拆礼物追踪功能一共做了十六页。Telegram 的整个发送流程只有四页，Duolingo 只要三页，因为两者一开始就选中了收礼人，金额一点即达。
有结账流程的产品，应优先做 checkout upsell。58 款应用中有 12 款上线了这个功能。整个开发量不过是一个开关、一个留言框和订单上的一列，而且面对的是已经掏出银行卡准备付款的用户。
周期性的文化节点适合做 occasion catalogue。有 19 款应用做了这个，是所有场景中最多的，而预写祝福语承担了大部分转化工作，所以预算应该花在写分类标签和祝福文案的人身上，而不是工程上。
订阅类产品应该做 subscription seeding，并给送礼人相应的回报。Thrive Market 用 30 美元店铺积分换取一名新会员，完全不用投广告。
用户之间的实时互动为社交送礼打开了大门。Telegram 和 Twitch 实际上是在做一场包装成礼物的曝光竞拍。这类功能在插画师画出一头泰迪熊之前，需要先准备好虚拟货币、充值流程和内容审核政策。
有共同目标或连续打卡记录的产品，做 progress gifting 是顺理成章的选择。58 款应用中有 2 款做了这个，中位数只要五页，任何已有好友列表的产品都够得着。应用知道谁落后了，一份有用的礼物比再弹一条通知有效得多。
其他所有场景依然能从礼品卡中受益，前提是设计师能赋予其真正的入口。余额储值功能的界面复杂度跨度极大：Urban Outfitters 仅需三个页面，而 Shopee 多达十七个，是研究中最宽泛的差异。这种差距表明，设计师是主动塑造了流程，而非简单拼凑页面。
结论
送礼功能的核心取决于时机，其次才是设计。在本研究的五十八款应用中，九个场景的主要区别在于它们选择发起询问的时机。其中八个场景将询问绑定在产品已掌握的事实上，比如购物车已满、日历上的日期、实时对话，或是进度落后于目标的共享任务。
无论产品上线哪种场景，发送流程中总会浮现同样的六个问题，从识别没有账号的收件人到决定双方可见的内容。领取页面让交易回款。当收件人收到朋友已付费的礼物时，这一功能最接近转化新用户的时刻。
这几个页面上的五项设计决策最终汇入数据库，落成一张拥有十七列的表。如果在开发者动手之前确定这些决策，代价只是一次沟通；反之，则面临数据迁移。
实际成本比看起来更低：结账处的开关功能只需几个页面，Duolingo 的共享进度功能也仅涉及五个页面。Duolingo 的“好友任务”早已识别出哪位学习者需要帮助——剩余三天、还需完成十五课——并精准地将二十颗宝石的经验值加速包放在发送者容易找到的位置。这份礼物的成本几乎为零。
研究中二十二款应用选择销售礼品卡，它们隐藏在“账户”菜单中，等待那些本就打算送礼的用户主动寻找。相比之下，“好友任务”页面的开发成本并无增加，且它恰好在用户已想到要送礼给哪位朋友的那一刻发起询问。