不同运营商应用推广方法

摘要

本发明涉及一种不同运营商应用推广方法。解决了现有技术的不足，技术方案为：如果运营商应用库存在整个应用库来源存在问题，则需要采用黑名单方式去掉不能使用的运营商应用来源，直接使用厂商应用库；如果运营商应用库存在来源库某个应用存在问题则进行单应用的黑名单处理，处理的技术手段为查找每个应用时进行一个AOP切面处理，查看是否属于黑名单为后端有个专门的服务持续判断那些单独被黑名单的应用是否恢复使用，恢复后从黑名单移除，根据下载地址直接进行一次http请求，发现正常后，从黑名单直接移除。

说明书

技术领域

本发明涉及一种应用推广方法，尤其是不同运营商应用推广方法。

技术背景

中国专利申请号：CN201310611301.3，公开日：2014年2月19日，公开了一种用于诊断应用推广渠道异常的方法和设备，提供了用于诊断应用推广渠道异常的方法和设备。该方法包括：(a)基于与所述应用推广渠道相关联的用户标识符的数目、终端标识符的数目、以及订户标识符的数目，确定所述用户标识符的数目是否异常；(b)基于在与所述应用推广渠道相关联的一个或多个终端上安装的应用之间的差异，确定平均差异应用数是否异常；以及(c)基于对所述用户标识符的数目是否异常进行的确定和/或对所述平均差异应用数是否异常进行的确定，确定所述应用推广渠道是否异常。但是由于产品被用于移动、联通、电信的营业厅；不通运营商有独有应用内容库；为了满足不同运营商推广各自想推广的应用，即使是同款应用，不同运营商的应用也会存在不同，同一运营商针对同款应用推广也会存在不同。

发明内容

本发明所要解决的技术问题是针对现有技术由于产品被用于移动、联通、电信的营业厅；不通运营商有独有应用内容库；为了满足不同运营商推广各自想推广的应用，即使是同款应用，不同运营商的应用也会存在不同，同一运营商针对同款应用推广也会存在不同的问题，提供一种针对不同运营商应用推广方法。

本发明解决其技术问题所采用的技术方案是：一种不同运营商应用推广方法，包括以下步骤：

步骤一，针对各自的来源，设立四套套应用库，分别为移动应用库、联通应用库、电信应用库和厂商应用库；

步骤二，针对不同运营商使用各自的应用库接口采取直推方式，当各自运营商不存在某应用采取厂商应用库补齐的方式，技术实现上采用proxy代理方式实现，入参告知当前客户端版本号，后台程序通过版本号知晓所属省份所属运营商；

步骤三，后台程序根据该省份的该运营商允许推广的应用来源，进行应用查找，查找顺序后端已定义完成；

在所述步骤一至步骤三中，如果运营商应用库存在整个应用库来源存在问题，则需要采用黑名单方式去掉不能使用的运营商应用来源，直接使用厂商应用库；如果运营商应用库存在来源库某个应用存在问题则进行单应用的黑名单处理，处理的技术手段为查找每个应用时进行一个AOP切面处理，查看是否属于黑名单为后端有个专门的服务持续判断那些单独被黑名单的应用是否恢复使用，恢复后从黑名单移除，根据下载地址直接进行一次http请求，发现正常后，从黑名单直接移除。可以满足新接入的运营商的应用推广需求；相互之间不会存在应用推广的干扰，各自推各自的；当各自应用不足时，采取厂商应用库填补，既满足运营商需求，又满足普通用户(产品使用者)的需求；例如：浙江移动、安徽移动虽然同属移动，他们采取相同策略，移动应用库，缺失的应用采取厂商应用库补齐，但是缺失的应用中有些应用是不允许推广的，则针对特定应用分省、分运营商采取黑名单策略；针对佣金应用：浙江移动、安徽移动有可能推广的某款应用从不同的CP(内容提供商)接入，因此他们推广的应用也会存在不同，这种情况下就采取多包的方式进行分发，浙江取浙江的这款应用，安徽取安徽的这款应用，也就是同款应用，同版本是并存的，针对不同的运营商下发不同的各自接入的CP应用。

作为优选，如果运营商应用库存在整个应用库来源存在问题，则需要采用黑名单方式去掉不能使用的运营商应用来源，直接使用厂商应用库；具体的做法为：根据事实数据统计，数据统计有下载异常的数据是通过客户端事实上报后端，后端根据pc的mac地址进行计算，30分钟内活跃用户中有超过500款应用25％的用户无法下载，某个来源库应用则黑名单掉该来源整库，进行黑名单该来源整库，黑名单的具体做法为在proxy前进行了一个AOP切面的前置通知，每个来源的查找都会进行该前置通知，依次进行，直到找到没有问题的应用库为止，如果最终都有问题，则下发空。

作为优选，步骤三中，如果运营商应用库存在来源库某个应用存在问题则进行单应用的黑名单处理，处理的技术手段为查找每个应用时进行一个AOP切面处理，查看是否属于黑名单，为了提高效率，黑名单应用保存在memcache当中。

作为优选，所述的应用为多包应用，所述多包应用为同款应用相同版本，在多包应用库中可以存在若干个，后台程序针对这种多包定义了一个参数外部渠道号，该渠道号由运营人员定义，通过运营后台决定在那个省份那个运营商使用，后续应用版本更新只要外部渠道号不变，则该包一直被该省份，该运营商使用，如需变更，运营在后台进行调整。

本发明的实质性效果是：可以满足新接入的运营商的应用推广需求；相互之间不会存在应用推广的干扰，各自推各自的；当各自应用不足时，采取厂商应用库填补，既满足运营商需求，又满足普通用户(产品使用者)的需求。

附图说明

附图1是实施例中假设的组织关系结构图。

附图2是实施例中假设的服务器架构图。

附图3是实施例中假设的组织关系节点说明图。

具体实施方式

下面通过具体实施例，并结合附图，对本发明的技术方案作进一步的具体说明。

实施例：

一种不同运营商应用推广方法，包括以下步骤：

步骤一，针对各自的来源，设立四套套应用库，分别为移动应用库、联通应用库、电信应用库和厂商应用库；

步骤二，针对不同运营商使用各自的应用库接口采取直推方式，当各自运营商不存在某应用采取厂商应用库补齐的方式，技术实现上采用proxy代理方式实现，入参告知当前客户端版本号，后台程序通过版本号知晓所属省份所属运营商；

步骤三，后台程序根据该省份的该运营商允许推广的应用来源，进行应用查找，查找顺序后端已定义完成；

在所述步骤一至步骤三中，如果运营商应用库存在整个应用库来源存在问题，则需要采用黑名单方式去掉不能使用的运营商应用来源，直接使用厂商应用库；如果运营商应用库存在来源库某个应用存在问题则进行单应用的黑名单处理，处理的技术手段为查找每个应用时进行一个AOP切面处理，查看是否属于黑名单为后端有个专门的服务持续判断那些单独被黑名单的应用是否恢复使用，恢复后从黑名单移除，根据下载地址直接进行一次http请求，发现正常后，从黑名单直接移除。

如果运营商应用库存在整个应用库来源存在问题，则需要采用黑名单方式去掉不能使用的运营商应用来源，直接使用厂商应用库；具体的做法为：根据事实数据统计，数据统计有下载异常的数据是通过客户端事实上报后端，后端根据pc的mac地址进行计算，30分钟内活跃用户中有超过500款应用25％的用户无法下载，某个来源库应用则黑名单掉该来源整库，进行黑名单该来源整库，黑名单的具体做法为在proxy前进行了一个AOP切面的前置通知，每个来源的查找都会进行该前置通知，依次进行，直到找到没有问题的应用库为止，如果最终都有问题，则下发空。

步骤三中，如果运营商应用库存在来源库某个应用存在问题则进行单应用的黑名单处理，处理的技术手段为查找每个应用时进行一个AOP切面处理，查看是否属于黑名单，为了提高效率，黑名单应用保存在memcache当中。所述的应用为多包应用，所述多包应用为同款应用相同版本，在多包应用库中可以存在若干个，后台程序针对这种多包定义了一个参数外部渠道号，该渠道号由运营人员定义，通过运营后台决定在那个省份那个运营商使用，后续应用版本更新只要外部渠道号不变，则该包一直被该省份，该运营商使用，如需变更，运营在后台进行调整。

以浙江移动为例说明：门店店员使用客户端装机助手时，首先识别为浙江移动某地市下某门店，然后找到该门店所属应用来源，接下来进行动态匹配，先找到该门店可使用应用库来源、接下来结合应用黑名单、多包综合分析适合这个点的应用(客户端装机助手存在登录入口，因此可以非常明确的知道该登录用户的所属组织结构信息，组织信息我们针对用户定义了一套渠道号规范，例如：浙江省杭州市西湖区文三路店，我们定义了一个渠道号2_zhydcmcc_0571_010050001_02008000001_，其中2_zhydcmcc_表示浙江移动、2_zhydcmcc_0571_表示浙江移动杭州、2_zhydcmcc_0571_010050001_表示西湖区、2_zhydcmcc_0571_010050001_02008000001_表示文三路店，这样可以从下级到上级层层递归查找所分配的应用)。

多包应用获取：以浙江移动为例，便于说明；附图1是组织关系结构，假设有A1….A6,B1…B5两款应用分配规则：A1…A6,B1…B5在下面组织至多存在一个点上；

组织节点：C1、C2、C3、C4、C1_1、C1_2、C3_1、C3_2……。

浙江移动组织结构如下：省、地市、区县、门店就是将某个应用与组织结构关联，继而分发使用；只会将某个CP的应用分配给某个组织。

以上所述的实施例只是本发明的一种较佳的方案，并非对本发明作任何形式上的限制，在不超出权利要求所记载的技术方案的前提下还有其它的变体及改型。