1.常见砍价工具的设计要点。

每个人都必须非常熟悉讨价还价的方法：讨价还价的发起人与朋友分享一个带有自己参数的链接。朋友帮助成功后，发起人可以以相应的底价获得产品。

目前市场上的讨价还价已经是一种比较成熟的营销方式，几乎很多大工厂都使用过，比如拼多多、Keep、唯品会等。

基本逻辑是通过更具吸引力的商品或礼品鼓励用户转发和分享，从而依靠发起者的社会关系链带来新用户或激活老用户。

通过体验市场上大部分的讨价还价游戏，我从用户的角度总结了一些讨价还价游戏的设计要点：

1.1对于讨价还价的发起人。

1.1.

这将测试平台的产品选择能力。所选产品必须针对目标用户。例如，对于男性用户，尽量少推销与目标用户群体差异较大的化妆品，否则会缩小讨价还价活动的用户群体。

1.2.

设计的要求是页面要有层次感，主次分明，排版布局中的核心动作和主要信息要更加明显。常见的策略是增加核心按钮的动态效果，引导点击，或者突出匹配的视觉。

1.

倒计时、跑马灯、进度条、激励脚本等信息具有较强的视觉冲击力，是营造氛围的好帮手。

1.2对于讨价还价的帮。

1.1.

讨价还价的老套路实际上消耗了朋友关系，近年来，每个人几乎都被一些人打败了。他们对这个程序太熟悉了，所以他们或多或少会抵制。

在制定活动策略时，我们应该从用户的角度思考如何减少对朋友关系的消费。你好，我好，大家好。有三种常见的方法:

从邀请形式扩展，如海报、小程序、H5、密码等，总有一个方便的用户点击形式；

优化邀请脚本，如设置一些有趣的邀请文案，增强好友氛围；

对于能够吸引帮手的奖励，这还是要根据用户画像进行选择激励。

1.2.

目前，许多工厂都是基于微信社会关系链的活动。最终目标是将流量引导到自己的平台。在此过程中，用户可能会打开站点外的页面、页面交互、引导和下载应用程序、安装、激活、注册和登录。

整个路径确实很长，如何缩短用户路径，也是一个值得探讨的问题。

基于市场产品体验和自己总结的一些规律，我准备抽象一套适合app的讨价还价游戏。

2.设计讨价还价工具。

2.

不要一上来就画原型，我们要明确讨价还价的具体业务流程：

业务流程更注重游戏本身，如何在每个环节开展业务，做好相关角色的分工，在逻辑和业务流程上形成闭环。

2.功能架构图。

业务流程图帮助我们了解讨价还价游戏中涉及的终端和角色，因此我们需要梳理终端和角色的一般功能结构：

整体会更加注重C端的交互，细节点比较多，需要特别注意。梳理完业务流程和一般功能框架后，我开始输出详细的产品方案。

2.方案设计。

2..

核心点：区分发起人、助手、用户关系链绑定、站外交互等。

1)启动人的视角。

发起人在APP站看到相应的活动，点击进入讨价还价活动页面。从发起者的角度来看，我们更关注活动状态、发起邀请和讨价还价的结果。因此，从这些角度来看，我大致整理了几个核心页面。

首先从整个页面浏览元素，分为：活动图片展示、讨价还价进度展示、启动邀请按钮和邀请记录展示。由于该方案是基于活动的角度，而不是从电子商务商品的角度，因此活动图片通常需要在后台进行配置。如果细节太详细，则方案中没有详细说明。

讨价还价进度：是简单的减少金额和剩余金额的计算结果。

削减金额：好友帮助削减的总金额；

剩余金额：可削减金额减去好友帮助削减的总金额(注：可削减金额=商品原价-商品底价)；

进度条&百分比：减少的金额/可见金额*100%。

邀请帮助btn：需要根据不同的活动状态进行操作指导。

未开始的活动：不可操作；

活动期间：引导发起邀请，点击直接调动共享控件，支持其他渠道共享；

成功讨价还价:指导可以以商品底价(例如0元)购买商品，点击跳转到相应的商品详情页，页面显示当前降价后的底价，并遵循支付流程；

讨价还价失败：一般也是在活动结束时呈现结果，给出讨价还价失败的提示。

邀请记录：展示帮助过的朋友和帮助过的金额信息。

活动未开始&无数据：展示无数据即可；

活动期间:展示帮助过的朋友和帮助过的金额信息。默认列表中只显示5个数据，支持扩展/收起查看数据；展示帮助朋友的头像、昵称和帮助成功的时间。

2)助人视角。

助手的链接可能比较长，毕竟从站内到站外分享，需要帮助人们从站外进入别人的邀请页面，并且有一些操作来引导回站内。

这里的另一个关键点是，有必要判断帮助人们是否安装了客户端。如果安装了，您可以直接调整应用程序；但是，如果未安装，则需要引导下载和安装。绑定设备跟踪和朋友关系链非常重要。

帮助人的实际帮助动作并不复杂，但也需要考虑以下场景：

活动尚未开始&已经结束：帮助人们看到的助力按钮是灰色的（这种互动将更加简洁和直观）；

活动期间：帮助好友，有两个操作结果，即成功或失败；

帮助结果:帮助成功:弹出窗口显示帮助削减的金额，引导帮助者开始讨价还价；帮助失败:还需要区分更详细的场景，如图所示，这里就不细说了。

C端交互的核心已经完成，关于成功讨价还价购买的过程和逻辑主要是从电子商务的角度来看，这里就不多说了，再看看B端配置。

后台设计2.3.2.

核心点：交易规则配置。

因为有必要抽象一套纯粹的活动配置工具，将整个讨价还价环节串联起来，所以我将在后台进行相对简单的阐述。核心功能是选择商品，设置讨价还价规则：

设定商品的原价和底价。

设定砍价人数/每人砍价幅度：帮助砍价人数。

这一块的处理逻辑类似于微信的幸运红包:让固定人数随机分配固定金额。我不会对其他次要信息罗嗦。

我没有重写后台监控的核心数据，大概列出几个：

PV、UV、助力页面的PV、UV。

讨价还价的发起人数，助力人数。

讨价还价成功人数，奖励领取人数。

站外拉活人数，站外拉新人数。

根据各自的业务指标，可以监控其他数据项。

3.重要的两点。

以上主要是纯C端和后台的配置说明，更重要的是：

3.1绑定用户关系链。

我们都知道，共享页面应该带来活动ID、共享userid和帮助人们的userid，但它涉及到引导和下载站外应用程序的操作，在这个过程中可能无法跟踪新的数据。因此，我们的策略是基于设备ID绑定好友关系链，然后花时间讨论。

3.2风控。

在开展活动时，我们必须做好风险控制，避免被收集。例如，在一个活动周期中，你只能为一个朋友讨价还价一次，不能为自己讨价还价，不能与用户黑名单系统对接等。在实际操作过程中，您必须特别注意。

4.拓展思路。

空间有限，其实有很多细节值得推敲：

根据分组设置议价金额:比如老用户可以帮助较少，新用户可以帮助削减更多，从而刺激发起人邀请更多的新用户；

根据群组设置奖励：例如，在新用户帮助成功后，您可以获得平台的会员体验权。一方面，它可以给予新注册用户一定的激励，另一方面，也有利于新用户后续关键行为的转变；

消息提醒要到位，及时:给即将成功讨价还价的用户配置消息提醒，在文案中给予更多的激励等，对用户也有一定的影响。