许可推荐服务的制作方法
在线应用商店(或“应用商店”)已经成为分发数字内容的主要方式。在应用商店模型中，开发者将其应用程序或其它此类内容上载到应用商店。终端用户通过他们的本地计算设备上的接口连接到应用商店，通过该接口，他们可以浏览应用商店中可获得的集合。一旦用户选择了应用，应用将被下载并安装在本地执行环境中。示例包括适用于
许多应用是在用户在应用商店中浏览时必须考虑的各种不同许可下提供的。例如，可以在家庭许可、企业许可或订阅许可下提供应用。用户可以在一个许可下获得应用，然后基于试错，稍后返回到应用商店以升级或以其它方式更改为不同的许可。一些应用允许试用期，在此期间用户可以“预览”应用而无需提交特定许可，但用户最终必须获得应用的常规许可。
在后台，开发者努力提供对终端用户具有吸引力的许可条款，还要满足开发者的业务目标。这可能涉及开发者使用系统和服务来发现客户如何使用他们的应用以便优化他们的许可产品。从更技术的角度来看，此类系统难以部署和维护，并且在多个开发者和应用之间复制时会浪费资源。
技术实现要素：
本文中公开了一种在线应用商店中的许可推荐服务。所述许可推荐服务收集与从所述应用商店下载的应用(或一些应用)的实际使用情况有关的使用情况信息。所述实际使用情况与用户在初始许可下如何使用应用相关。所述服务识别出可以非常适合于所述应用的所述实际使用情况的后续许可，并向所述应用在其中执行的本地执行环境传送推荐。所述推荐可以在用户移动到后续许可并且想要查看可用许可选项的上下文中呈现。
提供本发明内容以便以简化的形式对下面在具体实施方式中进一步描述的设计构思的选择进行介绍。可以理解的是：本发明内容并不旨在标识要求保护的发明主题的关键特征或重要特征，也不旨在用于限制要求保护的发明主题的范围。
附图说明
参考以下附图可以更好地理解本公开内容的许多方面。尽管结合这些附图描述了若干实现，但本公开内容不限于本文中公开的实现。相反，意图是涵盖所有替代方案、修改和等价物。
图1示出了许可推荐技术的实现中的操作环境。
图2示出了实现中的推荐过程。
图3示出了许可推荐技术的实现中的操作环境。
图4示出了实现中的推荐过程。
图5示出了许可推荐技术的实现中的操作序列。
图6示出了实现中的推荐过程。
图7示出了适用于实现本文中公开的许可推荐技术的计算系统，包括附图中示出的以及下面在具体实施方式中讨论的任何架构、单元、过程和操作场景以及序列。
具体实施方式
本文中公开的许可推荐技术增强了在线应用商店中的应用许可过程。在实现中，开发者可以将api集成到他们的应用中，以允许应用将其实际使用情况报告给在线应用商店。然后，应用商店可以通过为给定用户(基于他或她对应用的实际使用情况)推荐最佳许可来指导交易决策。在一些实现中，实际使用情况可以涉及用户在试用期间如何使用应用。在其它实现中，实际使用情况可能是在用户希望离开(升级、降级等)的常规许可下。
此类技术消除了从应用开发者/供应商监测用户行为的负担。从更技术的角度来看，该技术消除了在开发者和供应商之间重复系统的需要，从而节省了计算和通信资源。
图1示出了增强型许可技术的实现中的操作环境100。操作环境100包括在线应用商店101、开发者环境109和本地执行环境。在线应用商店101包括应用服务103和许可推荐服务105。本地执行环境111包括从在线应用商店101下载的应用的实例，由应用113表示。应用113包括应用编程接口api115，用于与许可推荐服务105进行接口。
在线应用商店101采用推荐过程200来进行许可推荐。下文针对推荐过程200对图2中所示的步骤进行了带括号的引用。
在操作中，开发应用并将其上载到在线应用商店101，以便数字分发到本地执行环境。可以在任何合适的系统或平台中开发应用，其中，开发环境109是代表性的。应用可以由多个供应商提供给在线应用商店101，使得在线应用商店101可以用作用户浏览和购买应用程序许可的中心点。
用户可以通过其计算设备上的专用应用商店应用，通过网络浏览器或经由某种其它合适的机制来浏览应用商店。应用服务103代表的应用服务托管店面界面并处理浏览和交易体验的各个方面。
一旦选择了应用，就将其从应用服务103下载到计算设备并安装在本地执行环境中(步骤201)。在该示例中，下载应用113并将其安装在本地执行环境111中。应用113在初始许可下安装。例如，初始许可可以针对使用情况的预览或试用期。在另一个示例中，初始许可可以是用户所选择的常规、非试用/非预览许可。
当用户参与并利用应用113时，api115报告由许可推荐服务105接收的应用的实际使用情况(步骤203)。许可推荐服务105对使用情况信息进行处理以识别后续许可来推荐给用户(步骤205)。为此，许可推荐服务105可以将实际使用情况与由应用的开发者提供的标准进行比较，该标准定义哪个可用许可最适合给定的使用情况简档。
可选地，可以将实际使用情况与可用许可中的一个或多个可用许可下的应用的其它实例的其它用户的实际使用情况进行比较。可以将目标用户的实际使用情况映射到从其它用户的使用情况开发的若干使用情况简档中的一个使用情况简档。然后，许可推荐服务105可以推断出最佳许可(以及要推荐的一个许可)是与最适合实际使用情况的使用情况简档相关联的一个许可。换句话说，每个可用许可可以与从观察到的其它用户的使用情况开发的若干使用情况简档中的一个使用情况简档相对应。然后，可以基于这若干使用情况简档中的哪一个使用情况简档最适合实际使用情况来将目标用户的实际使用情况映射到给定许可。
许可推荐服务105可以采用机器学习来将其它用户的使用情况简档映射到可用许可，以及连续地对映射进行更新。这可能具有额外的技术效果，即消除了开发者创建和提供映射的需求。相反，许可推荐服务105可以随时间发现哪些许可适合哪些使用情况简档(基于各种用户在各种许可下观察到的应用的使用情况)。
后续许可可以是，例如，可用于应用的各种常规许可中的一个特定许可。然后，许可推荐服务105向本地执行环境111传送许可推荐(步骤207)。该推荐识别出后续许可，使得它可以在应用113的用户接口、在线应用商店101的用户接口或某个其它接口中呈现。
作为示例，应用113可以呈现用户接口121，通过该用户接口121可以显示内容123和其它应用内容(例如，电子表格)。可以在应用113在用户接口121中展示的消息125的上下文中传送和显示由许可推荐服务105提供的许可推荐。
在一些实现中，消息125可以包括文本、视频或图像，或者描述所推荐的许可的其它此类内容。消息125可以随时间发生改变并且取决于用户如何与先前消息交互。作为图1中的简要示例，消息125随着时间的推移在外观和/或内容上发生改变。在试用期的第1天(或在其期间可以制定许可推荐的任何其它时段)，消息125以一种方式出现。在第15天，其外观/内容发生变化，在第30天，它的变化甚至更大。许可推荐服务105可以选择消息125的特性，并且可以控制它何时以及如何改变。或者，应用125控制如何在用户接口121中展示消息125。
图3示出了许可推荐技术的另一个实现中的操作环境300。操作环境300包括在线应用商店301、开发者环境309、本地执行环境311和位置执行环境321，以及通信网络310。在线应用商店301还包括应用服务303和许可推荐服务305。
本地执行环境311包括应用313，而本地执行环境321包括应用323。应用313表示在预览/试用基础上许可的应用的单个实例。应用323代表根据常规(非试用)许可下许可的应用的安装基础。应用311和应用323分别包括api315和api325。api315和api325提供应用311和323与许可推荐服务305之间的接口。
通常，应用323(以及类似的其它应用)将其实际使用情况经由api325报告给许可推荐服务305。许可推荐服务305使用机器学习来分析使用情况数据点，以便开发用于应用的可用许可的使用情况简档。应用313还可以将其实际使用情况经由api315报告给许可推荐服务305。许可推荐服务305用许可推荐消息进行回复，该许可推荐消息可以包括指示所推荐的许可的文本、图像、视频和/或其它内容。在一些实现中，许可推荐服务305可以可选地建议对由开发者提供的标准的修改，开发者可以在回复中提供确认。
在线应用商店301采用推荐过程400来向应用商店的客户进行许可推荐。下文针对推荐过程400对图4中所示的步骤进行了带括号的引用。
在操作中，开发应用并将其上载到在线应用商店301用于向本地执行环境的数字分发。应用可以由多个供应商从合适的开发者环境上载到在线应用商店301，其中开发者环境309是代表性的。开发者还为在线应用商店接收的每个应用提供使用情况标准(步骤401)。然后，客户可以将应用下载到他们的本地执行环境。
应用服务303托管店面界面，用户可通过该店面界面浏览通过应用商店提供的应用。可以在终端用户的设备上采用网页浏览器、专用应用或某种其它解决方案以促进这样的体验。一旦选择了应用，就将其从应用服务303下载到计算设备并安装在本地执行环境中。
使用情况标准定义了可用于每个应用的各种许可以及可能适用于每个许可的使用类型。例如，可以在家庭许可、企业许可和订阅许可或者它们的任意组合下提供应用。应用的使用情况标准可以指示个体许可适合于打算单独使用该应用的用户，而使用情况标准可以针对打算与其它人共享该应用的用户建议扩展的许可(例如，经由不同的计算机登录来识别)。在另一个示例中，使用情况标准可以建议用于家庭用户的家庭许可和用于商业用户的企业许可。在又一个示例中，可以针对一些使用情况模式建议一次性许可，而可以针对其它使用情况模式建议订阅许可。可以在使用情况标准中建议许多其它许可建议、使用情况模式等，并且可以认为这些许可建议、使用情况模式等在本公开内容的范围内。
许可推荐服务305从由应用323表示的应用的安装基础接收实际使用情况信息(步骤403)。应用通过存在于每个应用中的api来报告其各种许可下的实际使用情况。
在某些情况下，许可推荐服务可以选择性地修改由开发者环境309提供的使用情况标准(步骤405)。例如，许可推荐服务305可以从由应用的安装基础提供的实际使用情况信息中确定最适合每种类型许可的使用情况模式。如果模式与开发者指定的使用情况标准中表示的模式不同，则对标准进行修改以使其与观察到的模式一致。在这种情况下，许可推荐服务305可以通过服务和开发者环境309之间的自动反馈通道来通知开发者(步骤406)。用于提供反馈和接收对修改的批准的其它机制是可能的并且可以被认为是在本公开内容的范围内。
api315在处于试用模式时监测并报告应用313的实际使用情况。许可推荐服务305接收实际使用情况信息(步骤407)，并基于应用313的实际使用情况信息、其它用户的实际使用情况以及由开发者提供的(和/或由服务修改的)使用情况标准来继续识别要推荐的常规许可(步骤409)。然后，许可推荐服务325可以向本地执行环境311传送推荐的许可。
图5示出了操作序列500以进一步解释许可推荐技术的各个方面。操作序列500涉及操作环境300的元素及其交互。
在操作中，实体在开发者环境309中生成应用并将应用上载到应用服务303以通过应用商店接口分发给用户。使用情况标准伴随应用并存储在许可推荐服务305中。使用情况标准用于基于用户对应用的实际使用情况来评估针对给定用户的最合适的许可。
作为示例，将应用从应用服务303下载到本地执行环境311并且以试用的方式进行安装。用户与应用313交互并且其使用情况由api315监测。具体而言，api315监测触发何时向许可推荐服务305报告使用情况信息的各种关键事件。例如，api315可以在用户遇到用户接口中的特定元素时报告使用情况。或者，api315可以跟踪使用情况并定期报告，而不管用户如何使用该应用。
在此期间，向许可推荐服务305报告与该应用的其它实例的实际使用情况相关的其它使用情况信息。许可推荐可以鉴于由应用的其它实例提供的实际使用情况信息来修改开发者环境309提供的使用情况标准。当保证修改时，许可推荐服务305可以经由回到开发者的api来请求来自开发者环境309的批准。开发者处的人员可以审核所建议的修改并回复批准(或不批准)。
最终在应用313中发生关键事件，其触发api315向许可推荐服务305报告应用的实际使用情况。响应于该报告，许可推荐服务305识别要向用户推荐的常规非试用许可。许可推荐服务305将向应用313传送该推荐以使应用313在其用户接口中呈现。可以将该推荐传送给代替应用313或者除了应用313之外的不同的应用，例如用户设备上的应用商店应用或网页。
假设用户选择所推荐的许可，则应用313向应用服务303传送该选择。应用服务303更新其针对用户和应用的记录，并向开发者环境309报告该事务。可以理解的是：不同的应用可以代替序列的该部分中的应用313，例如应用商店应用或网页。
可以明白的是：在一些实现中，除了在线应用商店301之外，该许可推荐服务305还可以支持其它应用商店。例如，为了示例性目的，可以假设在线应用商店301支持用于
此外，针对其它平台开发的应用可以包括允许应用向许可推荐服务305报告使用情况信息的api。因此，许可推荐服务305可以考虑各种各样的用户和各种各样的平台上对特定应用的所有使用情况。因此，针对多个平台来开发应用产品。跨越多个平台的应用的使用情况信息可以由许可推荐服务305收集，并且在跨越所有平台生成许可推荐时被考虑在内。在一些场景中，可以随时间不同地展示许可推荐，以便增加用户最终与推荐交互的可能性。
在一些实现中，许可推荐服务305可以采用图6中的推荐过程600来向应用商店的客户进行许可推荐。下文针对推荐过程600对图6中所示的步骤进行了带括号的引用。
在操作中，开发者可以将应用上载到在线应用商店301以便分发给与商店相关联的终端用户。除了开发者可以提供与应用相关联的许可信息以外，该许可信息指定可用于应用的各种许可以及可能的其它细节(例如价格、特征描述等)。因此，许可推荐服务305接收许可信息(步骤601)。例如，开发者可以在上载应用时通过门户向许可推荐服务305提供许可信息。
例如，开发者可以经由提交门户体验l1和l2来指定两个或更多个许可选项。l1下的应用可以具有20个特征，而l2下的应用可以具有40个特征。l1和l2的价格点可以相同或者可以不同。每个许可选项还可以具有以基本术语描述它的标签，例如“基本”和“高级”。也可以在信息中指定试用期，例如，十五天或三十天。在某些情况下，开发者可以为每个许可指定多个价格点。开发者还可以能够为每个许可选项指定自定义消息。
用户可以在试用许可、预览等的有限时间段内为用户下载应用的实例。在初始时段结束时，开发者通常希望将用户转换为常规的非试用许可。
为了便于从试用许可转换到常规许可，应用跟踪应用的使用情况并将使用情况报告给许可推荐服务305。使用情况可以描述用户使用什么特征、用户使用应用的频率、用户是否共享该应用，或者应用可以跟踪和报告的任何其它类型的用户。许可推荐服务305接收使用情况信息(步骤603)并继续将其与应用可获得的其它许可的使用情况简档进行比较(步骤605)。根据比较来确定许可推荐(步骤607)。
使用上文的l1和l2的示例，可以将用户的使用情况与在l1下许可的其它用户的使用情况以及在l2下许可的其它用户的使用情况进行比较。如果使用情况符合在l1下优于在l2下的其它用户的使用情况，则选择l1作为推荐。如果使用情况符合在l2下优于l1的其它用户的使用情况，则选择l2作为推荐。
在某些情况下，应用中特定特征的使用可以决定推荐哪个许可。例如，开发者可以指示特征a和b的使用通常指示对l1的偏好，而特征c和d的使用通常指示对l2的偏好。因此，由应用向许可推荐服务305报告的使用情况信息可以包括提及用户使用哪些特定特征。如果使用特征a和b，则可以推荐l1，而如果使用特征c和d，则可以推荐l2。如果应用相对较新并且尚未对足够的其它用户进行采样以获得来自其使用情况的推荐，则这种相关性可能特别有用。
在一些实现中，特定许可选项的价格可以变化。例如，许可推荐系统305可以基于用户的过去购买历史和其它用户的购买历史来改变正在推荐的许可的价格。对于开发者而言一种选项可用于在许可信息中指定是否优化收益。如果启用该选项，则许可推荐服务305可以动态地、逐个用户地改变给定许可的定价。试用开始后经过的时间也可以作为因素考虑进许可定价。随着试用期的推进，许可可能会变得更贵或更便宜，这取决于哪种定价举措会优化收益。
在识别出向用户推荐哪个许可之后，许可推荐服务305识别如何向用户呈现该推荐(步骤609)。许可推荐可以以各种方式展示给用户，例如在用户不得不与之交互以便解除它的模态对话框中、用户可以忽略的无模式通知栏或其它类型的展示。
许可推荐服务305最终达成许可推荐并且将其呈现在考虑中的应用的用户接口、在线应用商店301的用户接口、或在某种其它用户接口中(步骤611)。在一些情况下，可以向用户展示一个或多个附加许可选项。虽然许可中的一个可以是由许可推荐服务305确定的推荐的一个许可，但是可以向用户展示第二选项以供考虑作为替代。
可以跟踪用户对推荐的参与并将其作为因素考虑到未来的推荐和展示中。例如，如果已经反复向用户推荐了高级许可，但是用户反复解除，则许可推荐服务305可以推断不再提供高级许可。而是可以将推荐改变为标准推荐，例如，其更有可能将用户转换为购买。
继续该示例，用户可以在展示了标准许可选项之后最终点击了解更多按钮。在下一次启动该应用时，鉴于知晓用户表现出对标准许可的兴趣，许可推荐服务305可以呈现标准许可推荐而不是再次呈现高级推荐。
以下是在office365上下文中讨论的操作示例。该示例中的许可推荐系统(lrs)利用关于用户收集的信息的聚合。可以在四个主要阶段中收集该数据。
在装载阶段期间，用户可以购买office365，或者可以获得试用期。在购买的情况下，无论用户在哪里购买(零售、应用商店、微软商店等)，当他们获得应用时，他们可以实际上购买针对office订阅的信用而不是该产品的任何特定的库存单位标识符(sku)。当用户购买或试用office365时，他们可能需要在客户端中激活它。在首次运行/装载体验中，可能会向用户询问有关他们自己及其产品意图的一些基本问题。可以存储这些问题的答案。然后，用户可以能够开始使用该产品。可能会问的问题的一些示例是：“你拥有什么设备？”以及“你打算用office做什么？”
还可以记录用户获得office的入口点，他们是否从活动电子邮件、在线广告等进入获取流程。
第二阶段涉及用户对产品的自然使用。可以给用户一段时间来使用具有其必须提供的所有特征的产品。在此期间，他们可能有机会探索这些特征、开发一些基本的使用模式、并利用可用的不同权益。可以不断测量使用模式和权益摄取。
也可以利用这个机会向用户推荐他们原本可能不会尝试的操作。这将有助于我们不仅了解用户会自然地发现什么，而且还了解哪些特征对用户有价值但对他们来说并不显而易见地去尝试。这可以通过利用诸如电子邮件、教学ui、模板、产品内消息传送等的消息传送选项来完成。
可以为每个平台上的每个应用收集该使用情况数据(例如，android手机上的excel、ipad上的word、在线office上的powerpoint)。基于关于用户的所有这些信息，一旦试用期结束或者在整个试用期期间，系统可以向用户展示对话，告知他们是时候选择他们的订阅。在每种情况下，系统可以基于迄今为止收集的关于它们的信息来为用户推荐sku。对于购买了office的用户，系统可以根据他们在购买时购买的信用量来向他们告知他们可以获得office多久。例如，如果他们购买了价值$69.99的信用额度，则他们可以获得12个月的office365个人版或9个月的office365家庭版。
第三阶段涉及相关活动。除了在此期间允许用户无限制地使用产品的时间之外，还可以从用户登录时所采取的其它活动中收集数据。也可以执行对用户前一次(或多次)在显示许可推荐时所采取的动作的分析。与系统仅检查office客户端使用情况相比，这可以提供更完整的用户视图，具有更细微差别和更好的整体描绘。
第四阶段涉及跨用户的聚合。基于来自先前用户的续订数据，查看用户的使用情况并决定要推荐的sku的算法还可以考虑具有相同行为的其它人的动作。例如，如果bob有1台pc安装、1台ipad安装和android手机安装，并且还与尚未使用任何订阅权益的2位用户分享了他的订阅，则系统目前会认为应该向他推荐office365家庭版，因为他已经分享了他的订阅。如果该算法发现具有与bob相同的使用情况详情的用户中的90％要么取消他们的订阅，要么最终以个人版结束，那么它将向bob以及与其类似的其它任何人提供office365个人版，因为对他来说这可能是最成功的sku。可以调整算法以优化用户价值、收益或平衡。
可以从若干入口点遇到许可推荐服务。如前所述，可以在初始装载时间结束时调用它以帮助用户选择初始sku。应用还可以随时请求推荐。使用的几个机会如下。
在续订时间(renewaltime)时，系统可以向用户提示针对他们的正确的报价，以允许他们评估他们的使用情况，并确定他们是想留在他们当前的sku还是切换到替代品。续订时间可以发生在试用期结束时、有限订阅期结束时，或者在用户可以考虑新许可的任何其它时间。对于组织而言，这可能只针对管理员。因此，在一些实现中，当开发者上载可用许可选项时，他们可以注释：仅当用户具有针对其定义的某些角色(例如，微软azure活动目录中的管理员角色)时才应显示某些许可选项。
虽然存在针对消费者用户的数据点的集合，但是存在关于商业用户的附加数据点，其中不仅可以在用户级别并且还可以在组织级别跟踪数据。例如，应用可以记录各种用户数据点并经由适当的api向许可推荐服务发送这些数据点。以下是系统可以跟踪的示例数据点列表，包括：
-特定设备上的应用安装的数量
-暗示被展示以在设备上进行安装的意图所采取的行动
-服务订阅权益的使用级别，例如，使用链接服务
-每个应用(在应用套件内)和每个平台的应用使用情况(范围从未安装和安装但未使用到常规用户)
-管理员(商业用户)是否已添加了用户以及应用服务支持消费者许可的共享的数量或应用服务是否支持消费者许可的共享、用户是否已共享其订阅(以及与多少客户共享)
-如果服务订阅支持多个成员/用户，那么
-主要用户是否是组织(商业)的一部分
-管理员是否添加了团队站点
-使用的补充内容
系统可以基于从以上各点收集的数据来对用户进行分组。基于到目前为止的业务观察，每个组可以具有初始推荐的产品。用户在他们采取不同的操作并使用或多或少的某些特征时可以在不同的组之间移动。可以实现机器学习算法以基于对整个组的上述数据的分析来改进针对特定用户组的推荐。
在一种实现中，可能是这样的情况：一个组织内的多个用户同时都尝试应用。这些用户可能会被认出，因为公共管理员为每个人安装了应用，或者因为他们都共享相同的电子邮件域名，或者通过某种其它机制。在这种情况下，使用情况数据实际上是跨用户汇集的。
例如，如果bob基于其使用情况被放入组1，则我们会基于系统迄今为止对客户的了解来最初向他推荐产品x。如果系统发现组1中75％的用户不购买产品x而是购买产品y，则机器学习算法将更新为以折扣率向组1中的人提供产品x，或者根据他们的数据向他们提供产品y。该算法将继续基于用户已经指示他们想要什么、用户已经使用了产品的哪些方面以及针对该组的推荐的先前成功率来细化产品推荐。
算法可以根据用户行为来建立模式，以允许系统针对尚未做出任何选择的用户预测正确的动作。推荐服务可以决定应该向用户推荐哪个产品以及如果有的话应该对该用户应用什么折扣。
算法可以知道用户是否在相同的组织中，并且在向该用户做出推荐时可以为该组织中其它人的使用情况赋予更重的权重。它还可以知道用户所处的组织的类型，并可以使用类似组织的行为来影响彼此的推荐。
在一些实现中，开发者可以具有他们的应用的不同功能级别，每个功能级别提供更高级别的权益。在应用商店的上下文中，开发者通常可以提交一个应用以及代表每个许可层级的多个价格点。例如，计费应用可以有三个层级—个人银行业务级别、一个用于小型企业的基本簿记，而另一个支持税务报告/归档功能。这些可以注册为许可l、许可2和许可3。每个许可还可以具有关联的一个或多个加售消息，例如“以<价格>购买contoso计费以保持对您财务的控制”或“通过contoso税务观察节省您的商业资金！现在以<价格>购买。”这些是许可1-消息1等。
接下来，开发者可以为每个许可设置某些价格点，例如：“$5.99”或“$9.99/月”。在一种实现中，开发者还可以设置弹性价格边界，例如，对于给定许可，最高价格为$5.99，而针对要花长时间来说服以进行购买/采取较低的价格点来说服以进行购买的用户，还可以设置给定许可的回退折扣价格点，例如“$3.99/月”。可以提交其它默认许可推荐(在系统的完整解释之后参见下文)。
还可以按照许可类型提交不同的描述性元数据(例如，应用标题、应用描述、应用屏幕截图)，反映与该特定许可相关联的特定能力集合。
最后，开发者将以上所有内容提交给应用商店开发者门户-应用(包)本身，常规描述性元数据和许可信息(许可层级、许可消息、许可价格点)。在应用商店的店面上，用户可以看到应用的三个列表，每个列表在具有各自的描述的不同(非折扣)价格点处。在另一个实现中，应用可以仅显示为一个列表，其具有查看每个许可选项的方式。
此时，应用在商店中可供用户发现和尝试。当用户尝试该应用时，安装它并运行。
应用在运行时可以将数据点发送回应用商店的集中式许可推荐数据输入服务。这可以在用户已经完成了可以指示特定许可的动作(例如，添加银行帐户的动作123或设置其公司名称的动作256、其月度余额大于200,000的动作982)时发生。该数据(具有第一次安装应用后136小时的形式，用户892采取动作256)被发送到应用商店服务。
应用可以定期轮询由应用商店服务运行的许可推荐服务，以获得针对该许可的推荐。开发者应用可以(基于其自身接口的布局)设计许可的最佳图形展示。这可以包括多个“外表”，每个外表可以显示推荐的许可，例如，每当应用启动时显示为细线通知栏，或者在30天试用即将结束时显示为更有力的模态弹出窗口。它也可以是由isv服务或应用商店服务发送给用户的电子邮件。
此时，每当应用运行时，它可以将数据点发送回推荐服务，并且它可以定期轮询应用商店推荐服务以查看它是否应该显示针对特定许可的特定消息。最佳地，显示了正确的许可-如果它太昂贵，则用户可以放弃该应用。如果它太便宜，则潜在的收益可能会丢失。
最后注意，作为对显示消息的响应，用户可以采取以下三种动作中的一种(1)缺乏兴趣(忽略/解除)(2)部分感兴趣(点击通知但不完成购买)(3)完全感兴趣(完成购买)。这是对显示什么推荐的最终反馈。
机器学习系统(在上面的部分中阐述)确定不显示消息还是显示针对特定许可的特定消息。机器学习系统的多种实现是可能的，并且下文描述的是许多实现中的一种。
机器学习系统跨越所有用户识别应用中的给定动作与所购买的特定许可之间的相关性(与正在购买的其它许可相比)。此外，如果每个许可可能有多个价格点，则系统会针对许可价格点对此进行重新计算。
注意，在机器学习算法的一些实现中，可以对在一时间段内发生的动作对(例如，(1)建立成本中心以及(2)分配的用户)进行分析。对于当前用户，系统计算许可置信度得分，即基于当前用户已经采取的动作集合，有什么证据支持与许可2和许可3相比应该推荐许可1。系统可以根据许可之间的价格差异来对推荐的许可进行加权。
例如，如果仅基于用户动作，推荐$9.99/月的许可的权重(0.51)与推荐$4.99/月的许可的权重(＝0.55)相比仅稍微减少，则应用商店可以修改许可置信度得分以纳入收益潜力，所以相比比较便宜的许可(＝0.58)，现在最后一组许可置信度得分会推荐较昂贵的许可(＝0.63)。
这种相对收益(基于收益对推荐进行偏置)对用户的价值进行加权(仅依赖于应用动作)的方式也可由开发者在提交时设置。
如果折扣定价可用，则可以执行与上述相同的计算来计算给定许可的给定价格点。在这种情况下，计算可以是计算用户在较高价格点完全购买应用的可能性相比用户在较低价格点完全购买应用的可能性。在试用开始时可以优选高价格点，而在试用将要结束时选择较低的折扣。
在所有用户中，对于给定的经过时间(例如，自应用试用开始以来的3天)，系统识别显示特定许可的用户特定消息与特定价格之间的相关性，以及他们实际购买的可能性。该计算可以包括先前向该用户显示的哪些通知的历史，例如，他们是否在第2天看到了许可1但忽略了它？
可选地，该计算可以包括在向用户显示给定的许可/价格点与用户实际完全放弃该应用之间的进一步相关性(即，高价格点吓跑了他们)。可以从特定推荐许可+价格点得分中减去该放弃得分。
最后，学习系统还可以计算最佳“基于用户动作的了解许可偏好的时间”。在一种实现中，这可能是：哪些用户动作与非基本许可购买在统计上最显著相关？在试用期内用户采取这些动作的典型(百分之80)时间是什么？请注意，数字80本身可以根据随时间获得的收益进行修改。
此数字的计算确定在显示第一个许可推荐之前要等待的天数。或者，可以开发更复杂的系统，其计算在试用开始后直到给定日期所采取的非基本许可用户动作的典型百分比。这可以用作显示给定许可推荐的阈值。这意味着如果用户在试用的早期确实针对非基本许可采取了具有很强权重的特定动作，则该推荐将在更早的时候显示，倘若它超过所选择的阈值。
最后，消息抑制系统需要通过试用长度来调节。等到30天试用的第30天才开始加售的任何系统可能无法给予用户足够的时间来购买-因此接近试用结束时应该降低显示消息所需的阈值。
此时，系统开发了以下内容。用户从商店获取应用并启动它以开始其试用。用户在应用内完成某些动作-这些动作将被发送回应用商店。在第4天之前的这些动作并未显示针对特定许可的特别有力的证据。此外，对该应用的非基本许可的购买最经常发生于显示很少在第4天之前完成的动作673和891的用户。在第四天，用户再次启动该应用。用户截至目前已经在应用中采取了某些动作。基于对应用的所有其它用户的分析，推荐许可2，并且推荐在价格点1处的消息1。此推荐的权重符合所需的阈值，因此其由应用商店服务返回给应用。
该应用现在向用户显示应用中的通知“购买小型业务计费，以保持您的业务只需$9.99/月”。他们碰巧忽略了该通知。将该用户的数据点发送回应用商店服务。
他们忽略了进一步的通知，并在第23天，他们再次使用该应用。这一次，由于他们更接近试用结束，因此对许可2的折扣价格的推荐得分高于对非折扣价格的推荐。用户看到新的折扣消息并完成购买。将该用户的该数据点发送回应用商店服务。
开发者可以在其仪表板中看到每个许可/价格点/消息的购买结果，并且他们可以更新这些结果中的每个结果。开发者最终可能会具有进一步的控制以建议默认值。例如，他们可以提交他们认为总是指示对某个许可的偏好的用户动作。在这样的情况下，如果用户采取了特定动作，则应用商店许可推荐服务可以始终推荐该许可。
他们还可以提交他们认为有时指示对某个许可的偏好的用户动作。在这样的情况下，这些数字形成了许可推荐服务的初始种子。但是，由于实际使用情况数据取代了开发者的最佳猜测，因此它们的权重(作为推荐的因素)会下降。
他们还可以提交默认消息/优选消息。在这样的情况下，这些数字形成了许可推荐服务的初始种子。但是，由于实际使用情况数据取代了开发者的最佳猜测，因此它们的权重(作为推荐的因素)会下降。
图7示出了计算系统701，其表示可以在其中实现本文中公开的各种应用、服务、场景和过程的任何系统或系统的集合。计算系统701的示例包括但不限于：服务器计算机、机架服务器、网络服务器、云计算平台和数据中心设备，以及任何其它类型的物理或虚拟服务器机器、容器和它们的任意变体或组合。其它示例可以包括智能电话、膝上型计算机、平板计算机、桌面式计算机、混合计算机、游戏机、虚拟现实设备、智能电视、智能手表和其它可穿戴设备，以及它们的任意变体或组合。
计算系统701还可以实现为单个装置、系统或设备，或者可以以分布式的方式实现为多个装置、系统或设备。计算系统701包括但不限于：处理系统702、存储系统703、软件705、通信接口系统707和用户接口系统709。处理系统702与存储系统703、通信接口系统707和用户接口系统709操作地耦合。
处理系统702加载并执行来自存储系统703的软件705。软件705包括推荐过程706，其表示针对前面的图1-图6讨论的过程，包括推荐过程200、400和600。当由处理系统702执行以增强许可推荐时，软件705指示处理系统702如本文中所描述的至少针对前述实现中讨论的各种过程、操作场景和序列进行操作。计算系统701可以可选地包括为了简明的目的而未讨论的额外的设备、特征或功能。
仍然参照图7，处理系统702可以包括微处理器以及从存储系统703取得和执行软件705的其它电路。处理系统702可在单个处理设备中实现，但也可分布于协作执行程序指令的多个处理设备或子系统之间。处理系统702的示例包括：通用中央处理单元、专用于应用的处理器和逻辑器件，以及任何其它类型的处理设备、它们的组合或变体。
存储系统703可以包括处理系统702可读的并且能够存储软件705的任何计算机可读存储介质。存储系统703可包括用于存储诸如计算机可读指令、数据结构、程序模块或其它数据的信息、以任何方法或技术实现的易失性和非易失性、可移动和不可移动的介质。存储介质的示例包括随机存取存储器、只读存储器、磁盘、光盘、闪存器、虚拟存储器和非虚拟存储器、磁盒、磁带、磁盘存储或其它磁存储设备，或者任何其它合适的存储介质。计算机可读存储介质在任何情况下都不是所传播的信号。
除了计算机可读存储介质以外，在一些实现中，存储系统703还可以包括可以通过其在内部或外部传输软件705中的至少一些软件的计算机可读通信介质。存储系统703可实现为单个存储设备，但也可在多个存储设备或相对于彼此是共置或分布式的子系统上实现。存储系统703可包括额外的单元，如能够与处理系统702或者可能其它系统通信的控制器。
软件705可以在程序指令中实现，并且可以在由处理系统702执行时，指示处理系统702如针对本文中说明的各种操作场景、序列和过程所描述的那样来进行操作，以及执行其它功能。例如，软件705可以包括用于实现许可推荐服务(例如105和305)的程序指令。
具体而言，程序指令可以包括协作或以其它方式交互以执行本文中描述的各种过程和操作场景的各种组件或模块。各种组件或模块可体现为经编译或解释的指令或者指令的某种其它变体或组合。各种组件或模块可以以同步或异步的方式、串行或并行、在单线程或多线程环境中，或者根据任何其它合适的执行范式、它们的变体或组合来执行。除了或者包括推荐过程706，软件705还可以包括附加过程、程序或组件，诸如操作系统软件、虚拟机软件或其它应用软件。软件705还可以包括固件或可由处理系统702执行的某种其它形式的机器可读处理指令。
概括地说，当被加载进处理系统702并执行时，软件705可以将总体来自通用计算系统的合适的装置、系统或设备(计算系统701所代表的)转变成定制以增强许可操作的专用计算系统。的确，存储系统703上的编码软件705可转变存储系统703的物理结构。物理结构的具体信息可依赖于本描述的不同实现中的各种因素。这些因素的示例可包括但不限于：用于实现存储系统703的存储介质的技术，以及计算机存储介质被表征为主要存储还是次要存储，以及其它因素。
例如，如果计算机可读存储介质实现为基于半导体的存储器，那么当程序指令被编码在软件705中，软件705可以转变半导体存储器的物理状态，例如通过转变构成半导体存储器的晶体管、电容器或其它分立电路元件的状态。类似的转变可以针对磁介质或光介质发生。在不脱离本说明书的范围的前提下，物理介质的其它转变是可能的，提供前述示例仅为了便利该讨论。
通信接口系统707可以包括允许通过通信网络(未示出)与其它计算系统(未示出)通信的通信连接和设备。一起以允许系统间通信的连接和设备的示例可包括：网络接口卡、天线、功率放大器、rf电路、收发机和其它通信电路。连接和设备可通过通信介质(如金属、玻璃、空气或任何其它合适的通信介质)进行通信以便与其它计算系统或系统网络交换通信。上述介质、连接和设备是公知的，并且不需在此详细讨论。
用户接口系统709是可选的，并且可以包括键盘、鼠标、语音输入设备、用于接收来自用户的触摸手势的触摸输入设备、用于检测用户的非触摸手势及其它运动的运动输入设备和其它相当的输入设备以及能够接收来自用户的用户输入的相关联的处理单元。诸如显示器、扬声器、触觉设备的输出设备和其它类型的输出设备也可以包括在用户接口系统709中。在一些情况下，输入设备和输出设备可组合在单个设备中，如能够显示图像和接收触摸手势的显示器。上述用户输入和输出设备是本领域公知的，并且不需在此详细讨论。
用户接口系统709还可以包括：可由处理系统702执行以支持上文讨论的各种用户输入和输出设备的相关联的用户接口软件。单独地或者彼此结合以及与其它硬件和软件单元结合，用户接口软件和用户接口设备可支持图形用户接口、自然用户接口或任何其它类型的用户接口。
计算系统701和其它计算系统(未示出)之间的通信可通过通信网络或一些网络并且根据各种通信协议、协议的组合或其变体来发生。示例包括内联网、互联网、因特网、局域网、广域网、无线网络、有线网络、虚拟网络、软件定义的网络、数据中心总线、计算背板或任何其它类型的网络、网络组合、或者它们的变体。上述通信网络和协议是公知的，并且不需在此详细讨论。然而，可以使用的一些通信协议包括但不限于：因特网协议(ip、ipv4、ipv6等)、传输控制协议(tcp)和用户数据报协议(udp)，以及任何其它合适的通信协议、变体或者它们的组合。
在其中交换数据、内容或任何其它类型的信息的任何上述示例中，信息的交换可以根据各种协议中的任何一种协议来发生，这些协议包括ftp(文件传输协议)、http(超文本传输协议)、rest(表述性状态转移)、网络套接字、dom(文档对象模型)、html(超文本标记语言)、css(层叠样式表单)、html5、xml(可扩展标记语言)、javascript、json(javascript对象表示法)和ajax(异步javascript和xml)，以及任何其它合适的协议、变体或者它们的组合。
从前述公开内容可以理解某些发明方面，以下是各个示例。
示例1。一种操作包括应用服务和许可推荐服务的在线应用商店的方法，所述方法包括：在所述应用服务中，将应用的实例下载到本地执行环境以便在初始许可下安装和运行；在所述许可推荐服务中，从所述应用的所述实例接收指示所述应用的所述实例在所述初始许可下的实际使用情况的使用情况信息；在所述许可推荐服务中，至少部分基于所述使用情况信息来识别要向用户推荐的来自所述应用的潜在许可集合的哪个许可，以及向所述应用服务传送识别出所述许可的许可推荐；以及在所述应用服务中，向所述本地执行环境传送所述许可推荐以供所述用户考虑。
示例2。根据示例1所述的方法，还包括：在所述许可推荐服务中，从与所述应用相关联的开发者平台接收针对所述潜在许可中的每个潜在许可的使用情况标准。
示例3。根据示例1-2所述的方法，其中，至少部分基于所述使用情况信息来识别要向所述用户推荐的所述许可包括：将所述实际使用情况与针对所述潜在许可中的每个潜在许可的所述使用情况标准进行比较。
示例4。根据示例1-3所述的方法，还包括：所述许可推荐服务从所述应用的其它实例接收指示在所述潜在许可中的一个或多个潜在许可下的所述应用的所述其它实例的其它实际使用情况的其它使用情况信息。
示例5。根据示例1-4所述的方法，其中，至少部分基于所述使用情况信息来识别要向所述用户推荐的所述许可包括：将所述实际使用情况与针对所述潜在许可中的每个潜在许可的所述使用情况标准进行比较。
示例6。根据示例1-5所述的方法，还包括：所述许可推荐服务基于所述其它使用情况信息来生成对所述使用情况标准的修改。
示例7。根据示例1-6所述的方法，还包括：所述许可推荐服务与所述开发者平台通信以获得对所述修改的授权。
示例8。根据示例1-7所述的方法，其中，向所述本地执行环境传送所述许可推荐以供所述用户考虑包括：在包括所述在线应用商店的店面界面的网页中呈现所述许可推荐。
示例9。根据示例1-8所述的方法，其中，向所述本地执行环境传送所述许可推荐以供所述用户考虑包括：在所述应用的所述实例的用户接口中呈现所述许可推荐。
示例10。一种计算装置，包括：一个或多个计算机可读存储介质；处理系统，其可操作地与所述一个或多个计算机可读存储介质耦合；以及应用的实例，其存储在所述一个或多个计算机可读存储介质上，并且包括程序指令，当由所述处理系统执行时，所述程序指令指示所述处理系统至少进行以下操作：在多个关键事件发生之间的时间段内监测所述应用的所述实例的实际使用情况；监测在所述应用的所述实例中发生的所述多个关键事件；响应于所述关键事件中的一个关键事件发生，识别所述关键事件中的所述一个关键事件与所述关键事件中的先前一个关键事件之间的所述时间段期间的所述应用的所述实例的所述实际使用情况；以及向从其下载所述应用的所述实例的在线应用商店中的许可推荐服务传送所述实际使用情况。
示例11。根据示例10所述的计算装置，其中，所述程序指令还指示所述处理系统响应于从所述许可推荐服务接收到许可推荐，在所述用户接口中呈现所述许可推荐。
示例12。一种计算装置，包括：一个或多个计算机可读存储介质；一个或多个处理系统；在线应用商店服务，其存储在所述一个或多个计算机可读存储介质上，并且包括程序指令，当由所述一个或多个处理系统执行时，所述程序指令指示所述一个或多个处理系统至少进行以下操作：将应用的实例下载到本地执行环境以便在初始许可下安装和运行；从所述应用的所述实例接收指示所述应用的所述实例在所述初始许可下的的实际使用情况的使用情况信息；至少部分基于所述使用情况信息来识别要向用户推荐的来自所述应用的潜在许可集合的哪个许可，以及向所述本地执行环境传送识别出所述许可的许可推荐。
示例13。根据示例12所述的计算装置，其中，所述程序指令还指示所述一个或多个处理系统：从与所述应用相关联的开发者平台接收针对所述潜在许可中的每个潜在许可的使用情况标准。
示例14。根据示例12-13所述的计算装置，其中，为了至少部分基于所述使用情况信息来识别要向所述用户推荐的所述许可，所述程序指令还指示所述一个或多个处理系统：将所述实际使用情况与针对所述潜在许可中的每个潜在许可的所述使用情况标准进行比较。
示例15。根据示例12-14所述的计算装置，其中，所述程序指令还指示所述一个或多个处理系统：从所述应用的其它实例接收指示在所述潜在许可中的一个或多个潜在许可下的所述应用的所述其它实例的其它实际使用情况的其它使用情况信息。
示例16。根据示例12-15所述的计算装置，其中，为了至少部分基于所述使用情况信息来识别要向所述用户推荐的所述许可，所述程序指令还指示所述一个或多个处理系统：将所述实际使用情况与针对所述潜在许可中的每个潜在许可的所述使用情况标准进行比较。
示例17。根据示例12-16所述的计算装置，其中，所述程序指令还指示所述一个或多个处理系统：基于所述其它使用情况信息来生成对所述使用情况标准的修改。
示例18。根据示例12-17所述的计算装置，其中，所述程序指令还指示所述一个或多个处理系统：与所述开发者平台通信以获得对所述修改的授权。
示例19。根据示例12-18所述的计算装置，其中，为了向所述本地执行环境传送所述许可推荐以供所述用户考虑，所述程序指令指示所述一个或多个处理系统：在包括所述在线应用商店服务的店面界面的网页中呈现所述许可推荐。
示例20。根据示例12-19所述的计算装置，其中，为了向所述本地执行环境传送所述许可推荐以供所述用户考虑，所述程序指令指示所述一个或多个处理系统：在所述应用的所述实例的用户接口中呈现所述许可推荐。
附图中提供的功能框图、操作场景和顺序、以及流图表示用于执行本公开内容的新颖方面的示例性系统、环境和方法。虽然为了使说明简单，本文中包括的方法可以是功能图、操作场景或顺序、或者流图的形式，并且可描述为一系列的动作，但是应该理解和明白的是：这些方法并不受限于动作的顺序，因为，与之相应，一些动作可以以不同的顺序发生和/或与本文中示出和描述的其它动作同时发生。例如，本领域技术人员将会理解和明白，方法能够可替代地表示为一系列相互关联的状态或事件(例如在状态图中)。另外，对于新颖实现来说，并非方法中说明的所有动作都是必需的。
本文中包括的描述和附图描绘了具体实现以便教导本领域的技术人员如何做出和使用最佳选择。出于教导发明原理的目的，一些常规方面已被简化或省略。本领域的技术人员将领会落入本发明的范围内的这些实现的变体。本领域的技术人员还将领会的是：可以以各种方式来组合上述特征以形成多种实现。因此，本发明不局限于上述具体实现，而是仅由权利要求及其等价物限定。
- 还没有人留言评论。精彩留言会获得点赞！