本申请涉及邀约信息处理
技术领域：
，特别是涉及邀约信息处理方法、装置及系统。
背景技术：
：在电子商务销售平台中，平台方经常会开展一些促销优惠活动等，甚至还有些销售平台采用“团购”等形式长期开展优惠活动，例如，“聚划算”等平台。在传统的招商体系中，通常是由平台制定好招商计划后，商家根据计划主动报名参加。这种方式的优势是能明确体现商家的参团意愿，但是这种方式的问题是在商家报名数过少的场景中，平台缺少选择性，并且，主动报名的商品质量不可控，平台缺乏主动权。在这种情况下，反向邀约顺势而生，所谓反向邀约即平台自己选品，然后邀请对应的商家来参加活动的方式，这种方式会让平台获得更多的主动权和灵活性，也为平台各种主动选品玩法提供支撑。但是目前的邀约系统几乎都不具备太多的通用性，要么只针对特定的场景进行邀约，要么邀约的方式不够灵活。技术实现要素：本申请提供了邀约信息处理方法、装置及系统，有利于节省邀约资源，提高邀约的转化率。本申请提供了如下方案：一种邀约信息处理系统，包括：邀约数据源配置模块，用于提供统一的数据源接入接口，并通过所述接口接收至少一个邀约数据源配置信息并保存，所述邀约数据源中记录有邀约对象信息；邀约方式配置模块，用于确定各邀约数据源对应的邀约方式配置信息并保存；邀约执行模块，用于根据所述邀约数据源配置信息以及所述邀约方式配置信息，生成邀约记录，并确定当前待发送的目标邀约记录，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。一种邀约信息处理方法，包括：服务端提供统一的数据源接入接口，每个待接入的邀约数据源以独立的模块实现所述接口；所述邀约数据源中记录有邀约对象信息；通过所述接口接收至少一个邀约数据源的配置信息；确定各邀约数据源对应的邀约方式配置信息；保存所述邀约数据源的配置信息以及所述邀约方式配置信息，所述邀约数据源的配置信息以及所述邀约方式配置信息用于生成邀约记录，并按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。一种邀约信息处理方法，包括：至少一个客户端生成邀约数据源；所述邀约数据源中记录有邀约对象信息；将所述邀约数据源以独立的模块实现服务端提供的统一接口；通过所述接口向所述服务端提交所述邀约数据源的配置信息，由所述服务端保存所述邀约数据源的配置信息，并确定各邀约数据源对应的邀约方式配置信息，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。一种邀约信息处理方法，包括：服务端保存至少一个邀约数据源的配置信息，以及对应的邀约方式配置信息；所述邀约数据源中记录有邀约对象信息；根据所述邀约数据源配置信息以及所述邀约方式配置信息，生成邀约记录；批量拉取当前待发送的目标邀约记录，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。一种邀约信息处理装置，应用于服务端，包括：接口提供单元，用于提供统一的数据源接入接口，每个待接入的邀约数据源以独立的模块实现所述接口；所述邀约数据源中记录有邀约对象信息；数据源配置信息接收单元，用于通过所述接口接收至少一个邀约数据源的配置信息；邀约方式配置信息确定单元，用于确定各邀约数据源对应的邀约方式配置信息；保存单元，用于保存所述邀约数据源的配置信息以及所述邀约方式配置信息，所述邀约数据源的配置信息以及所述邀约方式配置信息用于生成邀约记录，并按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。一种邀约信息处理装置，应用于至少一个客户端，包括：数据源生成单元，用于生成邀约数据源；所述邀约数据源中记录有邀约对象信息；接口实现单元，用于将所述邀约数据源以独立的模块实现服务端提供的统一接口；提交单元，用于通过所述接口向所述服务端提交所述邀约数据源的配置信息，由所述服务端保存所述邀约数据源的配置信息，并确定各邀约数据源对应的邀约方式配置信息，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。一种邀约信息处理装置，应用于服务端，包括：配置信息保存单元，用于保存至少一个邀约数据源的配置信息，以及对应的邀约方式配置信息；所述邀约数据源中记录有邀约对象信息；邀约记录生成单元，用于根据所述邀约数据源配置信息以及所述邀约方式配置信息，生成邀约记录；邀约发送单元，用于批量拉取当前待发送的目标邀约记录，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。根据本申请提供的具体实施例，本申请公开了以下技术效果：通过本申请实施例，提供了一套通用的邀约商家来参加平台开展的活动的技术解决方案，支持灵活的“可插拔式”的邀约数据源，支持不同邀约场景时的相互隔离互不干扰式的邀约方式。也就是说，通过同一个邀约系统，即可满足多种不同的邀约需求，从而有利于节省邀约资源，提高邀约的转化率。当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是本申请实施例提供的系统架构示意图；图2是本申请实施例提供的系统的示意图；图3是本申请实施例提供的第一方法的流程图；图4是本申请实施例提供的第二方法的流程图；图5是本申请实施例提供的第三方法的流程图；图6是本申请实施例提供的第一装置的示意图；图7是本申请实施例提供的第二装置的示意图；图8是本申请实施例提供的第三装置的示意图。具体实施方式下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。在本申请实施例中，提供了一套通用的邀约商家来参加平台开展的活动的技术解决方案，支持灵活的“可插拔式”的邀约数据源，支持不同邀约场景时的相互隔离互不干扰式的邀约方式。也就是说，通过同一个邀约系统，即可满足多种不同的邀约需求，从而有利于节省邀约资源，提高邀约的转化率。从系统架构角度而言，本申请实施例提供了一种邀约信息处理系统，该系统的用户主要是销售平台的运营人员。具体而言，销售平台在指定各种活动计划时，通常是由平台的运营人员向销售平台中的第一用户(主要是指商家用户、卖家用户等)发送邀约，例如，某销售平台中需要在某时间段内开展某促销活动a、促销活动b等多个活动，在现有技术中，通常需要为不同的活动圈定不同的邀约对象，然后，分别用各自的邀约资源进行邀约的发送，例如，运营人员使用自己的“旺旺”账号向各个邀约对象发送邀约消息，等等。而在本申请实施例中，运营人员只需要预先生成邀约数据源，然后接入到本申请实施例提供的通用型的邀约系统，另外还可以对邀约方式等信息进行配置，之后，该通用型的邀约系统就可以按照具体的邀约方式，向邀约数据源中相关的第一用户发送邀约。也就是说，本申请实施例中的邀约系统可以满足多种不同的邀约需求，并且，还可以为不同的邀约需求制定不同的邀约方式，包括邀约发送渠道、发送时间等等，不同邀约需求之间相互隔离，互不干扰。其中，邀约数据源即为待邀约的第一用户的数据对象集合，在具体实现时，可以分为人工选品和模型自动选品两种。因此，邀约数据源记录中除了指定数据对象以及第一用户信息之外，还可以包括邀约数据源的来源类型，标识了是人工选品还是模型自动选品，而模型自动选品又可以包括多种场景下的选品。另外，不同的邀约数据源还可以对应不同的邀约方式。为了能够使得来自于运营人员的邀约数据源能够接入到通用型的邀约系统，邀约系统可以提供一个统一的邀约数据源接口，这样，不同的邀约数据源各自可以以独立模块的方式实现该同一个邀约数据源接口，这样，邀约数据源就可以被添加到邀约数据源模块配置列表中。如果不再需要利用某邀约数据源进行邀约，则从配置列表中移除对应的模块即可，以此实现“可插拔式”的邀约数据源。具体实现时，邀约数据源模块配置列表主要包括如下配置字段：邀约数据源模块id；邀约数据源类型，可以包括人工选品、模型自动选品等；触发时间点：可以有多种表达形式，例如，0表示手动触发；1+时间列表，表示按指定时间点触发；2+时间间隔，表示按指定时间间隔定时触发，等。例如，具体实现时，邀约数据源模块配置列表中保存的信息可以包括：表1邀约数据源模块id邀约数据源类型触发时间点100001人工选品2+24小时100002模型自动选品0………………另外，在邀约系统中还可以提供邀约方式配置列表，也就是说，在本申请实施例中，邀约方式可以是可配置的。具体实现时，可以由运营人员根据需求进行配置，此时，配置的粒度可以是邀约数据源，也即，为每个邀约数据源配置对应的邀约方式；或者，还可以由邀约系统的工作人员进行配置，此时，配置的粒度可以是邀约数据源类型，也即，为每个邀约数据源类型配置对应的邀约方式，例如，为人工选品类型配置邀约方式1，为模型自动选品类型配置邀约方式2，等等。对于第二种情况，如果不同的邀约数据源对应相同的数据源类型，则可以使用相同的邀约方式，这样有利于节省邀约资源。具体的，邀约方式可以有多个字段上的信息组成，例如，可以包括：邀约数据源类型：邀约方式配置的粒度，当然，也可以以邀约数据源粒度进行配置；邀约触发时间点：可以与上述邀约数据源模块配置列表中的触发时间点形式一致；邀约消息内容：也即邀约消息中具体的文字、图片等内容，在不同的邀约场景，发送的邀约消息可能不同，具体消息内容可配置；邀约消息发送渠道：“旺旺”等即时通信系统、邮件、短消息等发送渠道，多种方式也可以进行组合；邀约过期时间：如24小时过期，过期的邀约链接不再有效；审核方式：人工审核、自动审核、自动审核+人工审核。例如，邀约方式配置表可以如以下表2所示：表2在上述邀约方式配置表中，是在邀约数据源类型粒度上对邀约方式进行的配置，此时，在具体针对某邀约数据源发送邀约时，可以首先通过查询表1，确定该邀约数据源对应的邀约数据源类型，然后，再通过查询表2，确定出该数据源类型对应的邀约方式，再按照该邀约方式，向对应的邀约对象发送邀约。在通过上述方式保存了邀约数据源配置表，以及邀约方式配置表的情况下，邀约系统就可以利用上述信息，发送具体的邀约。具体实现时，如图1所示，系统中还可以存在邀约数据源模块统一调度中心，该调度中心可以对出现邀约数据源模块配置列表中的所有模块实施调度。调度的方式就可以按照具体的邀约方式配置信息来确定。具体实现时，本申请实施例还可以对具体的邀约情况进行跟踪记录，以统计出具体的转化率等信息。为了便于进行该跟踪记录，具体在发送邀约之前，可以首先根据邀约数据源模块配置列表以及邀约方式配置信息，生成邀约记录列表，要列表中保存有待发送的邀约消息。来源于不同地方的邀约记录可以汇总到一个邀约记录表中，邀约执行模型可以从这个邀约记录表中读取邀约记录进行邀约。例如，具体的邀约记录列表中保存的信息可以如以下表3所示：表3邀约系统可以以较短的时间间隔定时执行邀约，每次执行邀约时，可以从邀约记录列表中批量拉取待发送的邀约记录，按照上述邀约方式配置中指定的方式向对应的第一用户发送邀约。本次发送完后，还可以在相应的邀约记录上打上邀约时间戳，如果同一条邀约记录执行了多次邀约，则可以形成时间戳列表，用于记录和跟进当前邀约记录的邀约发送情况。以上对本申请实施例的基本实现方式进行了介绍，下面对具体的实现方式进行更为详细的介绍。实施例一本申请实施例一首先提供了一种邀约信息处理系统，参见图2，该系统具体可以包括以下模块：邀约数据源配置模块201，用于提供统一的数据源接入接口，并通过所述接口接收至少一个邀约数据源配置信息并保存，所述邀约数据源中记录有邀约对象信息；邀约方式配置模块202，用于确定各邀约数据源对应的邀约方式配置信息并保存；邀约执行模块203，用于根据所述邀约数据源配置信息以及所述邀约方式配置信息，生成邀约记录，并批量拉取当前待发送的目标邀约记录，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。其中，邀约数据源配置模块201可以通过预置的接口接收邀约数据源的信息，包括具体的数据源id以及数据源类型等等，并可以添加到预置的邀约数据源列表中。当然，在实际应用中，除了通过邀约数据源列表方式保存邀约数据源信息，还可以通过其他方式进行保存，例如配置文件等。其中，具体的邀约数据源中就可以保存邀约对象信息，具体可以是数据对象信息。由于数据对象通常是由具体的第一用户发布的，因此，通过数据对象id等信息，即可查询到相应的第一用户，进而，就可以向这种第一用户发送邀约。邀约方式配置模块202接收到的配置信息可以是由邀约系统中的工作人员录入，或者，还可以由具体邀约需求方的运营人员录入，等等。并且，邀约方式配置信息的粒度可以有多种，可以在邀约数据源粒度上进行配置，还可以在邀约数据源类型粒度上进行配置，等等，具体可以根据实际的需求而定。所谓的邀约方式主要就是指邀约的出发时间点配置信息、发送渠道配置信息、过期时间配置信息等等。类似的，除了通过配置表的方式保存，邀约方式配置信息也可以通过配置文件等其他方式进行保存。邀约执行模块203主要是用于根据具体的邀约数据源配置信息以及邀约方式配置信息，按照具体的邀约方式配置信息，向具体的第一用户发送邀约。也就是说，多种不同的邀约需求都可以通过该系统进行统一的发送，同时可以在不同的邀约数据源之间可以形成隔离，互补干扰，还可以实现定制化的邀约方式，更为灵活。为了便于对具体的邀约状态等信息进行记录，在执行具体的邀约操作之前，还可以首先根据所述邀约数据源配置信息以及所述邀约方式配置信息，生成邀约记录，通过邀约记录列表等形式进行保存。这样，邀约执行模型每次执行邀约时，都可以从批量拉取当前待发送的目标邀约记录，然后，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。需要说明的是，在具体实现时，该系统还可以包括：去重模块，用于对不同邀约数据源产生的相同邀约记录进行去重处理。这是因为，在本申请实施例中，是将多个邀约需求方的邀约进行统一的发送，同一个第一用户可能会出现在不同的邀约数据源中。在多数情况下，邀约需求方在提交邀约数据源时，通常是与具体的活动等相关联的，也即，邀请具体数据源中的第一用户参加具体的某活动，此时，虽然第一用户同时出现在不同的邀约数据源中，但是，由于是邀请要第一用户参加不同的活动，因此，可以即使第一用户接收到多次邀约也是能够接受的。但是，还有一些情况是，邀约数据源可能与具体的活动等无关，此时，如果同一第一用户出现在不同的邀约数据源中，则可能会导致该第一用户收到多条邀约消息，而消息的内容可能是相同的，此时，可能会对第一用户造成干扰。因此，针对上述情况，本申请实施例还提供了去重模块，可以在发送具体的邀约之前，对不同邀约数据源产生的相同邀约记录进行去重处理。从这一点上而言，本申请实施例提供的邀约系统，除了能够实现通用性，还可以将不同的邀约数据源产生的邀约记录进行横向对比，去除一些重复操作，因此，可以起到节省邀约资源的作用。另外，还有一些邀约数据源配置信息中可能配置了排他性的要求，例如，要求邀约系统在发送邀约时，针对其数据源中包括的第一用户，不可以向其发送其他邀约，针对这种需求，也可以通过上述去重模块进行控制。另外，第一用户在报名参加某活动时，平台方通常会对第一用户及其数据对象的资质等进行一系列的规则检查，如果不能通过，则无法报名成功，这是平台对第一用户及数据对象质量把控的一种必要手段。但是，实际运营中发现，在反向邀约的方式下，由于是平台邀约第一用户来参加活动，而第一用户在接收到邀约之后来报名时竟然不成功，这对第一用户而言体验是非常不好的，也会对平台产生不好的影响。因此，在本申请实施例中，在邀约第一用户之前，还可以进行一次规则过滤，只有通过规则的第一用户才会发起邀约，否则不发送邀约。也就是说，该系统还可以包括：规则过滤模块，用于在发送邀约之前，按照预置的规则对所述待发送的目标邀约记录进行过滤。需要说明的是，关于对第一用户的规则过滤操作，在生成邀约数据源时通常已经执行过过滤，即邀约数据源中的邀约记录其实已经是过滤规则之后的记录，但是从邀约记录产生到开始发送邀约，中间是有一个时间差的，这段时间内规则或者数据对象状态可能已经发生变化(比如商品被下架等)，因此，在发送邀约时可以再过滤一次。此次过滤时所使用的过滤规则，可以是由邀约系统制定的统一的规则，各条邀约记录都可以依据来规则进行过滤。如前文所述，在邀约发送之后，如果第一用户接受了邀约，并且报名参加对应的活动，则通常还可以对第一用户以及对应的数据对象进行审核，以保证第一用户及其数据对象的参加资质。通常，邀约审核主要包括人工审核和自动审核两种，在本申请实施例中，也可以为邀约商品定制专属的审核流程。也就是说，业务方可以根据自身的需要，为不同的邀约场景下的邀约记录指定不同的审核方式。在优选的实现方式中，均可以采用的自动审核的方式，即第一用户接受邀约并报名时，只要通过了报名审核，报名成功，系统会对数据对象立即审核通过。这是因为，如前所述，邀约记录的甄选是很严格的，并且也已经过滤过一系列规则，所以这里直接审核通过是可行的。相对于主动报名而言，无论是从审核的时间、还是审核的通过率而言，邀约自动审核都是有绝对优势的，这对邀约系统的体验以及对第一用户的吸引力上都具有很大帮助。也就是说，本申请实施例提供的系统中还可以包括：审核模块，用于接收到邀约对象返回的接受邀约的消息后，如果所述邀约对象的报名审核通过，则将对应的数据对象置为审核通过状态。除了以上所述各模块，该系统还可以包括：跟踪记录模块，用于在针对所述目标邀约记录发送邀约后，将发送邀约的时间戳信息添加到对应的目标邀约记录中。另外，还可以包括：统计模块，用于对邀约执行过程中的转化率进行统计。该统计模块主要是监控邀约过程中的第一用户及数据对象的转化率与流失率的情况，除了能帮助邀约业务方对邀约的转化率、流失率数据有所了解，也可以对邀约中出现的各种状况做出及时应对。并且，在本申请实施例中，上述跟踪统计过程可以分阶段进行，也即，可以将邀约执行过程划分为多个阶段，分别统计每个阶段的转化率、流失率等数据，阶段划分越细，则越容易定位到具体的问题。其中，各阶段的转化率统计结果可以用于对所述邀约方式配置信息进行优化，还可以用于提供给邀约需求方，由所述邀约需求方对所述邀约数据源进行优化。下面对上述分阶段进行跟踪统计的过程进行详细介绍。反向邀约的流程实际上可以包括三步：a.通过人工或者模型选到的数据对象，汇总到待邀约的数据对象列表，生成邀约数据源；b.邀约系统读取待邀约数据对象列表，按照指定的邀约方式配置，分别向对应的第一用户发送邀约；c.第一用户收到邀约信息，接受邀约，报名数据对象，审核通过后，通过预置的流程参加活动。以上三步中，可能产生流失的情况可以体现在以下四个阶段：阶段一：发送邀约阶段，在该阶段，邀约可能成功发送到第一用户客户端，也可能发送失败，如果发送失败，则接收不到邀约的第一用户必然会流失掉，对应的数据对象也会流失；阶段二：第一用户成功接收到邀约，在该阶段，第一用户可能会点开邀约链接阅读具体的邀约消息内容，也可能不点开邀约链接，甚至直接删除，对于没有点开邀约链接或者直接删除的第一用户，也是流失掉的用户，对应的数据对象也会流失；阶段三：第一用户成功点开邀约消息内容，在该阶段，第一用户可能会接受邀约，也可能会拒绝邀约，拒绝邀约的第一用户也属于流失掉的用户，对应的数据对象也会流失；阶段四：第一用户接受邀约，在该阶段，第一用户可能报名成功，也可能报名不成功，对于报名不成功的用户，属于流失掉的用户，对应的数据对象也会流失。可见，每一阶段都可能会流失掉一部分邀约对象(第一用户的数据对象)，若将进入某一阶段时的邀约商品数计为a，经过这一阶段流失之后剩下的邀约商品数计为b，则这一阶段的邀约转化率为：阶段转化率：r＝b/a；最终的转化率即各阶段转化率之积，该总转化率体现了从发邀约到最终第一用户接受邀约并报名成功的成功率，总转化率越高，意味着邀约系统的效率就越高，可用性也就越好，对邀约资源的浪费也就越少，所以提升各阶段的转化率就成了优化邀约系统的重要手段。如前文所述，邀约模块各阶段的转化率的优化主要包括两个方面：邀约模块自身的优化、邀约数据源的优化。前者可以直接提升系统转化率，后者则会反馈给模型自动选品部分，同时也可以指导人工选品，从而间接提升邀约转化率。下面分阶段描述：1)阶段一转化率现象：对于选定的待邀约数据对象列表，只有部分数据对象发出了邀约。原因：规则过滤导致(去重过滤不计入本阶段转化率)。方案：提前在邀约数据源产生阶段统一过规则，这就可以将这一阶段的转化率提升到95％以上，本阶段已经不是转化率提升解决的主要矛盾。至于已经通过规则的数据源，在发邀约时再次因为规则原因导致过滤不通过，主要是因为邀约的数据对象在数据源产出到邀约发出之间，商品状态已经发生变化，或者该数据对象已经通过主动报名的方式报过名了。2)阶段二转化率现象：第一用户收到了邀约链接，但是却没有点击原因：通过对本阶段邀约数据的分析，可以根据第一用户是否真正看到邀约提示分为两种情形：a.看不到：通知渠道问题b.看到了：商家意愿问题方案：对于通知渠道问题导致的转化率低：a.支持即时通信系统、邮件、短信等多渠道方式组合发送；b.同时，不同时间点，第一用户的消息触达率(第一用户收到并且查看消息)是不一样的，因此，对发送时间也可以进行优化，例如，可以避免在凌晨时间发送，等等；c.在邀约系统不变的情况下，消息一次触达率会维持在某个范围内基本不变，可以通过多次发送消息的方式提升总的消息触达率。当然，第一用户一天接收的消息种类、数量都是非常多的，所以也不能发送过于频繁，以免对第一用户造成困扰。对于第一用户意愿问题导致的转化率低：即第一用户已经查看了邀约消息，但是因为自身原因考虑，不接受邀约。对此，可以通过对邀约数据源端的优化来解决。3)阶段三转化率现象：第一用户点击了邀约链接，进入了邀约页面，但是却拒绝了邀约。原因：主要还是第一用户因为主观或者客观的原因，不愿意接受邀约。比如，“聚划算”参团会要求第一用户入驻、数据对象需要有质检报告等，这些都会影响第一用户最终是否接受邀约报名。方案：对于这种情况，可以通过在邀约数据源端优化来解决。4)阶段四转化率现象：第一用户在邀约页面接受了邀约，开始报名，最终没有报名成功。原因：第一用户主观上是有意愿接受邀约的，但是却因为一些客观原因，比如规则无法通过、数据对象库存问题等，导致报名没有通过。另外，还可能由于报名流程太长，导致第一用户虽然接受了邀约，但是最终放弃了报名，等等。方案：对于数据对象库存问题等原因，可以通过在邀约数据源端优化来解决，而对于报名流程太长等原因，则可以提示业务方对报名流程等进行优化。通过上述可见，各个阶段的转化率低问题，大部分都可以通过对邀约数据源进行优化来解决。其中，人工或者模型会基于经验或规则在一个大的数据对象池子中进行选品，使用多种方案进行过滤，最终形成一小部分数据对象，投入邀约数据对象列表。邀约数据源端的优化正是为了保证发出邀约的数据对象最大可能的接受邀约并报名成功，这样就可以保证邀约资源的最小化浪费。优化的策略主要可以通过对第一用户回访、邀约各阶段的数据分析，得到影响转化率的数据对象及对应第一用户的主观以及客观的因素，进行迭代优化。优化的方向主要包括但不限于以下几方面：第一，数据有效性：a.一个月内多次参团的第一用户，无论从平台的角度还是从第一用户本身的意愿的强烈程度，都无需邀约系统进行干预，即不用邀约，这种第一用户通常会采用主动参加活动的方式报名。b.已经报名并审核通过的数据对象，不再邀约。对于这种数据对象，即便邀约进来也无法通过审核规则了，属于无效邀约。c.前一次邀约还未结束的数据对象，不再邀约。邀约发出后通常是需要为第一用户报名预留一段时间的，此即邀约有效期的概念，比如一天，这样，如果上一次邀约没有结束，这次邀约也就不需要了，属于重复无效邀约。第二，质量控制：对数据对象的品质控制，包括是否仿品、假货等检查，对第一用户资质的控制，包括第一用户诚信度、退货率等进行检查。第三，主观意愿的表达：a.多次邀约都没有报名的第一用户，体现了第一用户因数据对象或自身没有意愿接受邀约，不用再次邀约；b.明确拒绝邀约的第一用户(在阶段三中，第一用户可以明确拒绝邀约)，分析第一用户拒绝的原因，比如“退订消息，不再接受邀约“的第一用户，以后不再邀约。总之，通过分阶段的转化率统计，可以使得转化率过低的原因得到细化，从而可以用于指导邀约系统的优化，或者对业务方邀约数据库的优化，通过多伦的迭代，可以起到提高转化率，节省邀约资源的目的。实施例二该实施例二是与实施例一相对应的，从服务端的角度提供了一种邀约信息处理方法，其中，这里的服务端就可以是指邀约平台的服务端，具体的，参见图3，该方法可以包括以下步骤：s301：服务端提供统一的数据源接入接口，每个待接入的邀约数据源以独立的模块实现所述接口；所述邀约数据源中记录有邀约对象信息；s302：通过所述接口接收至少一个邀约数据源的配置信息；s303：确定各邀约数据源对应的邀约方式配置信息；s304：保存所述邀约数据源的配置信息以及所述邀约方式配置信息，所述邀约数据源的配置信息以及所述邀约方式配置信息用于生成邀约记录，并按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。具体实现时，在确定各邀约数据源对应的邀约方式配置信息时，可以接收针对各邀约数据源提交的邀约方式配置信息。或者，还可以接收针对各种邀约数据源类型提交的邀约方式配置信息，然后，根据邀约数据源所属的类型，确定对应的邀约方式配置信息。实施例三该实施例三是与上述实施例二相对应的，从客户端的角度提供了一种邀约信息处理方法，其中，这里的客户端可以是指邀约平台为具体的邀约需求方提供的客户端，具体形式可以包括app，或者还可以是通过浏览器访问的网页，等等。具体的，参见图4，该方法具体可以包括以下步骤：s401：至少一个客户端生成邀约数据源；所述邀约数据源中记录有邀约对象信息；s402：将所述邀约数据源以独立的模块实现服务端提供的统一接口；s403：通过所述接口向所述服务端提交所述邀约数据源的配置信息，由所述服务端保存所述邀约数据源的配置信息，并确定各邀约数据源对应的邀约方式配置信息，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。实施例四该实施例四是与实施例一相对应的，从服务端的角度，对邀约的具体执行进行介绍。具体的，参见图5，该实施例四提供了一种邀约信息处理方法，可以包括以下步骤：s501：服务端保存至少一个邀约数据源的配置信息，以及对应的邀约方式配置信息；所述邀约数据源中记录有邀约对象信息；s502：根据所述邀约数据源配置信息以及所述邀约方式配置信息，生成邀约记录；s503：批量拉取当前待发送的目标邀约记录，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。具体实现时，还可以对邀约执行过程中的转化率进行统计。在本申请的优选实施例中，所述邀约执行过程可以分为多个阶段，所述对邀约执行过程中的转化率进行统计具体可以为：对邀约执行过程中各阶段的转化率分别进行统计。在分阶段进行统计后，可以根据各阶段的转化率统计结果用于对所述邀约方式配置信息进行优化。例如，可以对邀约的发送时间、发送渠道和/或发送次数进行优化。或者，还可以将所述各阶段的转化率统计结果用于提供给邀约需求方，由所述邀约需求方对所述邀约数据源和/或业务规则进行优化。具体的，可以将预置时间段内多次报名参加活动的第一用户名单提供给所述邀约需求方，由所述邀约需求方将该第一用户关联的数据对象从邀约数据源中删除。或者，将已经报名并审核通过的数据对象信息提供给所述邀约需求方，所述邀约需求方将该数据对象从邀约数据源中删除。或者，将上一次邀约过程尚未结束的数据对象提供给所述邀约需求方，所述邀约需求方将该数据对象从邀约数据源中删除。或者，将邀约次数超过预置阈值但均未报名的第一用户名单提供给所述邀约需求方，所述邀约需求方将该第一用户关联的数据对象从邀约数据源中删除。或者，将执行过拒绝邀约行为的第一用户名单提供给所述邀约需求方，所述邀约需求方将该第一用户关联的数据对象从邀约数据源中删除。关于上述实施例二、三、四，各步骤的具体实现可以参见实施例一中的记载，这里不再赘述。与实施例二相对应，本申请实施例还提供了一种邀约信息处理装置，参见图6，该装置应用于服务端，包括：接口提供单元601，用于提供统一的数据源接入接口，每个待接入的邀约数据源以独立的模块实现所述接口；所述邀约数据源中记录有邀约对象信息；数据源配置信息接收单元602，用于通过所述接口接收至少一个邀约数据源的配置信息；邀约方式配置信息确定单元603，用于确定各邀约数据源对应的邀约方式配置信息；保存单元604，用于保存所述邀约数据源的配置信息以及所述邀约方式配置信息，所述邀约数据源的配置信息以及所述邀约方式配置信息用于生成邀约记录，并按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。具体实现时，所述邀约方式配置信息确定单元具体可以用于：接收针对各邀约数据源提交的邀约方式配置信息。或者，在另一种方式下，所述邀约方式配置信息确定单元具体可以用于：接收针对各种邀约数据源类型提交的邀约方式配置信息，并根据邀约数据源所属的类型，确定对应的邀约方式配置信息。与实施例三相对应，本申请实施例还提供了一种邀约信息处理装置，参见图7，该装置应用于至少一个客户端，包括：数据源生成单元701，用于生成邀约数据源；所述邀约数据源中记录有邀约对象信息；接口实现单元702，用于将所述邀约数据源以独立的模块实现服务端提供的统一接口；提交单元703，用于通过所述接口向所述服务端提交所述邀约数据源的配置信息，由所述服务端保存所述邀约数据源的配置信息，并确定各邀约数据源对应的邀约方式配置信息，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。与实施例四相对应，本申请实施例还提供了一种邀约信息处理装置，参见图8，该装置应用于服务端，包括：配置信息保存单元801，用于保存至少一个邀约数据源的配置信息，以及对应的邀约方式配置信息；所述邀约数据源中记录有邀约对象信息；邀约记录生成单元802，用于根据所述邀约数据源配置信息以及所述邀约方式配置信息，生成邀约记录；邀约发送单元803，用于批量拉取当前待发送的目标邀约记录，按照所述邀约方式配置信息中指定的方式，向对应的邀约对象发送邀约。具体实现时，该装置还可以包括：统计单元，用于对邀约执行过程中的转化率进行统计。其中，所述邀约执行过程包括多个阶段，所述统计单元具体可以用于：对邀约执行过程中各阶段的转化率分别进行统计。另外，该装置还可以包括：优化单元，用于根据各阶段的转化率统计结果用于对所述邀约方式配置信息进行优化。具体的，所述优化单元具体可以用于：对邀约的发送时间、发送渠道和/或发送次数进行优化。另外，该装置还可以包括：转化率提供单元，用于将所述各阶段的转化率统计结果用于提供给邀约需求方，由所述邀约需求方对所述邀约数据源和/或业务规则进行优化。具体实现时，所述转化率提供单元具体可以用于：将预置时间段内多次报名参加活动的第一用户名单提供给所述邀约需求方，所述邀约需求方将该第一用户关联的数据对象从邀约数据源中删除。另外，所述转化率提供单元具体还可以用于：将已经报名并审核通过的数据对象信息提供给所述邀约需求方，所述邀约需求方将该数据对象从邀约数据源中删除。或者，所述转化率提供单元具体还可以用于：将上一次邀约过程尚未结束的数据对象提供给所述邀约需求方，所述邀约需求方将该数据对象从邀约数据源中删除。再者，所述转化率提供单元具体还可以用于：将邀约次数超过预置阈值但均未报名的第一用户名单提供给所述邀约需求方，所述邀约需求方将该第一用户关联的数据对象从邀约数据源中删除。或者，所述转化率提供单元具体还可以用于：将执行过拒绝邀约行为的第一用户名单提供给所述邀约需求方，所述邀约需求方将该第一用户关联的数据对象从邀约数据源中删除。总之，本申请实施例提供了一套通用的邀约商家来参加平台开展的活动的技术解决方案，支持灵活的“可插拔式”的邀约数据源，支持不同邀约场景时的相互隔离互不干扰式的邀约方式。也就是说，通过同一个邀约系统，即可满足多种不同的邀约需求，从而有利于节省邀约资源，提高邀约的转化率。通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。以上对本申请所提供的邀约信息处理方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。当前第1页12