一、产品推广怎么做效果好啊，有哪些渠道呢？

可以在大型的B2B平台做产品发布推广，比如是阿里巴巴，淘宝，中国制造网等等。

或者是通过做搜索引擎的优化，实现推广效果。

或者是在多人流集中的地方做宣传。

或者是做大众媒体的推广，比如是电视，广告等等。

二、在CJ展上看到淘宝在推二维码什么是手机二维码啊？

手机二维码是二维码技术在手机上的应用。 二维码是用特定的几何图形按一定规律在平面（二维方向上）分布的黑白相间的矩形方阵记录数据符号信息的新一代条码技术，由一个二维码矩阵图形和一个二维码号，以及下方的说明文字组成，具有信息量大，纠错能力强，识读速度快，全方位识读等特点。将手机需要访问、使用的信息编码到二维码中，利用手机的摄像头识读，这就是手机二维码。当然，你可以用手机在虚拟购物墙上购买商品，向淘宝就可以实现手机扫码购物。

三、什么是渠道二维码？有什么用途?

渠道二维码，就是公众平台提供了生成带参数二维码的接口。每一个推广二维码，都代表不同的推广渠道。

小猪cms依据此接口开发了渠道二维码作用 :商家可通过微渠道对渠道来源进行管理，实现粉丝来源追踪。用户扫描后，公众号可以接收到事件推送。

“渠道二维码”将实现渠道的透明化、信息化管理，统计的即时性更是提高了渠道管理的效率，并且可能让全民直销时代成为现实，通过微信网络将每一个人的商业价值发挥到极致。用于支付等应用方便为了满足用户渠道推广分析的需要，公众平台提供了生成带参数二维码的接口。使用该接口可以获得多个带不同场景值的二维码，用户扫描后，公众号可以接收到事件推送。

渠道二维码作用 :此功能可以让商家微信公众号生成无限个专属ID的推广二维码，每一个推广二维码，都代表不同的推广渠道，商家可通过微渠道对渠道来源进行管理，实现粉丝来源追踪

“渠道二维码”将实现渠道的透明化、信息化管理，统计的即时性更是提高了渠道管理的效率，并且可能让全民直销时代成为现实，通过微信网络将每一个人的商业价值发挥到极致。

渠道二维码的应用:

利用“渠道二维码”监测推广效果

1、对不同渠道的推广效果进行精准追踪。

假如你分别在公交站台、报纸、电视媒体投放了一则广告，你可以通过“渠道二维码”将这三个推广渠道分别生成一个独立的二维码，通过不同二维码关注的粉丝，在“微渠道”后台可以清楚的知道粉丝来源，从而对推广渠道的效果的进行分析，选择优质的推广渠道，节省推广成本。

2、“渠道二维码”让微信用户成为你的推广员，实现线下病毒推广。

利用“渠道二维码”，我们的微信公众平台可以实现线下病毒推广，每个微信用户都可能成为你的推广员，我们可以给每个推广员一个独立二维码，粉丝通过推广员的专属二维码关注微信公众号后，推广员即可获得相应的奖励。

利用“渠道二维码”实现分销管理

1、“渠道二维码”可轻松实现分销渠道信息化管理。

厂家总部可以利用“渠道二维码”搭建官方微信商城，总部可以给所有代理商、经销商分配一个专属微信二维码，用来管理每个代理商或者经销商在微信商城上的销售情况;每个分销商每天的粉丝增长状况、销售状况，你同样可以了如指掌。

2、增强代理商推广积极性。

分销渠道的信息化管理，可形成厂家和渠道商合力来推广一个微信公众平台的良性局面，最终集成全国所有代理商的资源合力推广总部品牌，扩大品牌影响力，从而促进每个代理商业绩增长。

四、如何统计app push 推送效果统计

首先需要澄清一点的是，友盟统计分析服务不会统计，也不能统计设备上App卸载的信息的，友盟统计分析服务只会针对集成友盟统计分析SDK的App提供类似新增、日活、留存等基本指标，或者是开发者自定义的一些统计信息，如自定义事件等。

统计卸载信息其实是在友盟推送SDK里面做的，并且当前统计到的卸载信息也已经部分应用在了消息推送服务里面。接下来就提问者感兴趣的如何统计卸载设备，以及我们目前如何使用这部分卸载信息简单给大家讲一讲，太细节的东东就不便透露了。当然，我们的卸载只是针对Android平台来做的，iOS上由于苹果的限制，卸载统计从技术上是很难实现的。

先来说说友盟推送是如何统计卸载:

如果一个设备上有多个集成友盟推送SDK的App的话（注意，必须是集成了友盟推送SDK的App），我们把这些个App称为一个群组或者联盟，同一个群组内的App在推送的通道上是做了很多互保和优化工作的，比如长连接通道就是在这多个App之间共享的。

同一个群组里面的App，如果有某个App发生卸载行为的话，那么这个卸载事件就可以被群组里其它没有卸载的App所知晓，该卸载事件就可以上报给服务器端，服务器端就可以知道哪台设备上哪个App被卸载了。同一个群组内的App之间互相检测卸载是一种常用的手段，但是这个要依赖于设备上集成友盟推送SDK的App有很多个，形成一个群组，如果只有1个App集成了友盟推送的话，那么这种手段是无法捕获到卸载的。 群组内的App越多，卸载统计收集的效果越好。

写到这里，肯定有一部分开发者要问，如果设备上只有1个集成友盟推送SDK的App的话，那么如何统计到这个App是否被卸载了呢？ 这种情况下，我们只能判断到一部分卸载的情况，外加一些其它的辅助判断信息。

那么哪部分可以统计到呢？ 其实还是要依赖于App群组了，假设之前这个设备上只有App A集成了友盟推送，并且A被卸载了，假设后续又安装了集成友盟推送SDK的App B，那么如果给App A发消息，消息送达设备后(因为App B在，所以消息走的是B建立长连通道), 会尝试投递给App A，因为A已经被卸载了，所以投递是不成功的，App B就能感知到这一事件，因此也可以把该卸载信息上报回友盟服务器，服务器也就知道该设备上A App已经被卸载了，其实还是要依赖于设备上的App群组功能。

如果该台设备上后续一直没能有集成友盟推送SDK的App被安装，那么我们只能通过粗糙的看多少天不活跃，比如180天不活跃的App，我们认为这台设备上App已经被卸载了（有一定的偏差，比如某些工具类App，有可能打开频率就非常低），这个不一定准确，但是根据活跃度做用户分层多少也能看出来App的健康度。

接下来再谈谈为什么推送服务要收集设备上App的卸载信息的:

这个其实是和推送的一个硬指标“送达率”戚戚相关的，对于卸载的App，消息肯定是下发不了的，所以在评估送达率的时候，得把这部分卸载的量踢掉，否则在评估和计算送达率的时候，会导致送达率的下降或者不准确。

举个简单地例子，假设某个App有100W的装机量，过了一段时间有20W的卸载（根据我们的观察，20%的卸载率就算平均水平了），那么一次发送任务加入送达了40W的App，那么最终的送达率应该是 40W/(100W-20W) = 50%, 而不是 40W/100W = 40%。 卸载设备的统计越准确，对于最终送达率的评估效果越好。

最后我们来说说卸载统计在友盟推送服务中的应用:

首先在每次推送任务的时候，对于提交过来的device-token，我们会做一次清理，把卸载设备清理掉，所以有时候App开发者或者App运营人员会发现，他们提交的发送总数和友盟后台显示的当次发送数对不上，那就是因为友盟后台已经剔除掉了当次发送任务中的卸载设备了。

其次，当前的卸载统计我们还在进一步的分析和评估中，如果我们收集到的卸载设备数量足够准确，足够全面的时候，我们会把这个功能开放出来，放到统计分析系统里面供App开发者和运营人员来做参考。