一种数据处理方法、装置、设备以及存储介质与流程

1.本公开涉及人工智能技术领域，尤其涉及云计算、大数据和智能搜索技术领域，具体涉及一种数据处理方法、装置、设备以及存储介质。


背景技术：

2.随着互联网技术的发展，网络应用越来越广泛，用户可通过网络应用浏览信息，为了向用户提供更好的服务，需要在用户授权的情况下，了解用户在网络应用上的访问路径。


技术实现要素：

3.本公开提供了一种数据处理方法、装置、设备以及存储介质。
4.根据本公开的一方面，提供了一种数据处理方法，包括：
5.在数据已授权的情况下，获取携带有会话标识的第一交互请求；
6.获取所述第一交互请求关联的访问页面地址；
7.根据所述会话标识和所述访问页面地址，确定所述会话标识关联的访问路径。
8.根据本公开的另一方面，提供了一种电子设备，该电子设备包括：
9.至少一个处理器；以及
10.与所述至少一个处理器通信连接的存储器；其中，
11.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开任一实施例所述的数据处理方法。
12.根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使计算机执行本公开任一实施例所述的数据处理方法。
13.根据本公开的技术，解决了目前难以较为完整的获取用户访问路径的问题，为访问路径的获取提供了一种新思路。
14.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
15.附图用于更好地理解本方案，不构成对本公开的限定。其中：
16.图1是根据本公开实施例提供的一种数据处理方法的流程图；
17.图2是根据本公开实施例提供的另一种数据处理方法的流程图；
18.图3是根据本公开实施例提供的另一种数据处理方法的流程图；
19.图4是根据本公开实施例提供的另一种数据处理方法的流程图；
20.图5是根据本公开实施例提供的另一种数据处理方法的流程图；
21.图6是根据本公开实施例提供的多方交互实现数据处理的流程示意图；
22.图7是根据本公开实施例提供的一种数据处理装置的结构示意图；
23.图8是用来实现本公开实施例的数据处理方法的电子设备的框图。
具体实施方式
24.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
25.图1是根据本公开实施例提供的一种数据处理方法的流程图。本公开实施例适用于如何生成用户访问页面的访问路径的情况。该方法可以由数据处理装置来执行，该装置可以采用软件和/或硬件的方式实现，并可集成于数据处理系统所在的电子设备中，其中，该数据处理系统可以是一个系统，也可以是由多个相互交互的子系统构成。如图1所示，本实施例提供的数据处理方法可以包括：
26.s101，在数据已授权的情况下，获取携带有会话标识的第一交互请求。
27.其中，会话标识可以是表征一段时间内，用户端与数据处理系统交互过程的唯一性标识。例如，可以是半个小时内，用户端与数据处理系统所有的交互过程(如访问产品界面、进行产品下单和产品沟通等)都对应同一个会话标识。需要说明的是，本实施例的会话标识携带在交互请求中，优选的，该会话标识可以携带在交互请求的请求头中。
28.本实施例的第一交互请求可以是指用户端与数据处理系统交互过程中所涉及的所有请求。例如，可以包括但不限于：页面访问请求、下单请求、产品沟通请求和订单信息处理请求等中的至少一种。每个第一交互请求中都携带有表征本次交互过程在预设时段内对应的会话标识。在预设时段内的，同一用户端向数据处理系统发送的各第一交互请求中携带的会话标识相同。
29.可选的，本实施例在获取第一交互请求前需要得到数据方(如用户端)的授权。具体的，可以是用户首次(或每次)与数据处理系统交互时，数据处理系统向该用户发送数据获取授权申请，若用户同意，则表明数据处理系统得到了该用户端的数据获取授权，即该用户端的数据(如发送的交互请求、访问页面地址、会话标识以及订单相关信息等)对数据处理系统已授权。
30.在用户端的数据对数据处理系统已授权的前提下，用户端每次与数据处理系统交互，向数据处理系统发送携带有会话标识的交互请求(即第一交互请求)时，数据处理系统就会获取该第一交互请求。
31.s102，获取第一交互请求关联的访问页面地址。
32.其中，访问页面地址可以是第一交互请求被响应后，向用户端反馈的待展示页面的网页地址。例如，若第一交互请求是访问产品1详情信息的请求，则此时该访问页面地址为展示产品1详情信息的网页地址。具体的，可以是数据处理系统响应该第一交互请求，也可以是数据处理系统将该第一交互请求转发至其他系统，由其他系统来响应，对此不限定。
33.可选的，本实施例获取第一交互请求关联的访问页面地址的方式有很多，对此不进行限定。例如，可以是数据处理系统响应该第一交互请求确定出需要向用户端反馈的访问页面地址后，即获取了该访问页面地址。若第一交互请求的访问页面地址不是数据处理系统确定的，则数据处理系统还可以在用户端设置埋点，由埋点采集用户端发送第一交互
请求后所展示的访问页面的地址(即访问页面地址)，并将该访问页面地址反馈给数据处理系统。也可以是数据处理系统将该第一交互请求发送至存储有各交互请求关联的访问页面地址的第三方设备，从第三方设备处获取第一交互请求关联的访问页面地址等。
34.s103，根据会话标识和访问页面地址，确定会话标识关联的访问路径。
35.可选的，数据处理系统可以从第一交互请求中提取该交互请求的会话标识。具体的，可以是先从第一交互请求的请求头中提取该会话标识，然后再基于该会话标识和获取的该第一交互请求关联的访问页面地址，生成会话标识关联的访问路径。示例性的，可以是基于预设规则，对同一会话标识的各访问页面地址进行处理，得到该会话标识的访问路径；还可以是将获取的会话标识和访问页面地址输入到预先训练好的路径生成模型中，该模型就会基于输入的会话标识和访问页面地址，生成对应的访问路径。
36.示例性的，若数据处理系统先后获取5个第一交互请求，即交互请求1至交互请求5，其中交互请求1至交互请求3中携带有会话标识1，交互请求4和交互请求5中携带有会话标识2，且交互请求1至交互请求5关联的访问页面地址为地址1至地址5，则本实施例可以基于会话标识1和地址1至地址3，确定会话标识1的访问路径：地址1-地址2-地址3；基于会话标识2和地址5至地址5，确定会话标识2的访问路径：地址4-地址5。
37.本实施例的方案，通过获取携带有会话标识的第一交互请求，以及该第一交互请求的访问页面地址，基于该会话标识和访问页面地址，生成该会话标识关联的访问路径。本实施例中，访问路径关联的会话标识是从交互请求中获取的，而非从访问页面地址中提取。由于访问页面的地址在多页面跳转的过程中，容易丢失标识，所以本实施例从交互请求中提取的会话标识的稳定性更好，进而基于该会话标识关联的访问页面地址更全面，即生成的该会话标识的访问路径更完整。
38.图2是根据本公开实施例提供的另一种数据处理方法的流程图，本实施例在上述实施例的基础上，进一步给出了，在获取的第一交互请求为多个不同时刻的第一交互请求的情况下，如何“根据会话标识和访问页面地址，确定会话标识关联的访问路径”进行详细解释说明。如图2所示，本实施例提供的数据处理方法可以包括：
39.s201，在数据已授权的情况下，获取携带有会话标识的第一交互请求。
40.s202，获取第一交互请求关联的访问页面地址。
41.s203，按照第二交互请求的发起时间的顺序，将访问页面地址串联，得到会话标识关联的访问路径。
42.其中，第二交互请求为携带有同一会话标识的第一交互请求。
43.可选的，本实施例可以是先基于各第一交互请求中携带的会话标识，将携带有同一会话标识的第一交互请求作为一组第二交互请求，即将第一交互请求分为多组第二交互请求。每组第二交互请求又进一步包括至少一个第二交互请求，然后针对每组第二交互请求，根据至少一个第二交互请求的发起时间，将各第二交互请求按照发起时间的先后顺序进行排序，并按照各第二交互请求的时间先后顺序，将各第二交互请求关联的访问页面地址串联起来。例如，可以将各访问页面地址按照其对应交互请求的发起时间，依次串联在第二交互请求携带的会话标识后面。
44.示例性的，若一组第二交互请求为：交互请求1、在交互请求1对应的访问页面1上发起的交互请求2，以及在交互请求2对应的访问页面2上发起的访问请求3，则此时基于该
组第二交互请求的会话标识1，以及访问页面1的地址1至访问页面3的地址3，生成的会话标识1的访问路径为：会话标识1-地址1-地址2-地址3。
45.本实施例的方案，通过获取携带有会话标识的第一交互请求，以及该第一交互请求的访问页面地址，并将携带同一会话标识的第一交互请求关联的访问页面地址进行串联得到该会话标识的访问路径。本实施例方案是对批量的交互请求进行处理，为每种会话标识生成一条访问路径。通过批量处理可以降低操作复杂的，进而降低数据处理系统的功耗。
46.进一步的，本技术实施例也可以是实时获取第一交互请求，即在数据已授权的情况下，获取的携带有会话标识的第一交互请求的数量为一个时，此时执行根据会话标识和访问页面地址，确定会话标识关联的访问路径，可以包括：获取会话标识已关联的访问路径；根据访问页面地址，更新会话标识已关联的访问路径。具体的，本实施例可以是在实时获取到第一交互请求后，先从该第一交互请求中提取会话标识，然后查找基于该会话标识，是否生成过访问路径，即该第一交互请求是否为一段时间内，用户端与数据处理系统的首次交互，若是，则未生成过访问路径，否则生成过访问路径；若生成过访问路径，则获取该会话标识基于该段时间内已获取的第一交互请求生成的访问路径，即该会话标识已关联的访问路径，将本次获取的第一交互请求的访问页面地址串联在已关联的访问路径的后面，从而更新该会话标识已关联的访问路径。例如，若当前接收到的第一交互请求中携带会话标识1，该第一交互请求的访问页面地址为地址4，且获取到该会话标识1已关联的访问路径为：地址1-地址2-地址3，则基于该地址4更新后的会话标识1已关联的访问路径为：地址1-地址2-地址3-地址4。若未生成过访问路径，则基于将本次获取的访问页面地址直接串联在会话标识后面，生成该会话标识关联的访问路径。本实施例方案是对实时获取的交互请求进行处理，来实时更新每种会话标识的访问路径。通过实时处理提高会话标识关联的访问路径的实时性。
47.图3是根据本公开实施例提供的另一种数据处理方法的流程图，本实施例在上述实施例的基础上，进一步给出了如何生成携带会话标识的交互请求的过程。如图3所示，本实施例提供的数据处理方法可以包括：
48.s301，响应于获取到用户端执行交互请求生成操作，且在预设时段内，用户端已执行过交互请求生成操作，则获取用户端在预设时段的会话标识，并将会话标识添加到用户端当前生成的交互请求中。
49.可选的，本实施例的数据处理系统可以在用户端嵌入一个生成会话标识的组件，该组件可以检测用户端当前是否正基于用户在用户端的操作执行交互请求生成操作，若检测到正在生成交互请求，则进一步判断用户端在预设时段(如半个小时)内，是否执行过交互请求生成操作，即进一步判断该用户端在预设时段内是否生成过交互请求，若是，则获取数据处理系统之前为该预设时段内用户端与数据处理系统的交互分配的会话标识，并将该会话标识添加到用户端当前生成的交互请求中，具体的可以添加到交互请求的请求头中。若否，则为该预设时段内用户端与数据处理系统的交互分配一个的会话标识，如可以是嵌入到用户端的该组件生成。然后将该会话标识添加到用户端当前生成的交互请求中。
50.s302，在数据已授权的情况下，获取携带有会话标识的第一交互请求。
51.s303，获取第一交互请求关联的访问页面地址。
52.s304，根据会话标识和访问页面地址，确定会话标识关联的访问路径。
53.本实施例的方案，通过嵌入到用户端的组件，在检测到用户端执行交互请求生成操作时，为该交互请求确定会话标识，添加到新生成的交互请求中，且为一段时间内，用户端与数据处理系统交互的所有请求都添加相同的会话标识。保证了一段时间内，用户端与数据处理系统交互过程的会话标识的唯一性和稳定性(即不易丢失)，另外添加会话标识的过程对于用户端是无感知的。
54.图4是根据本公开实施例提供的另一种数据处理方法的流程图，本实施例在上述实施例的基础上，进一步给出了，一种应用会话标识关联的访问路径的优选实例，如图4所示，本实施例提供的数据处理方法可以包括：
55.s401，在数据已授权的情况下，获取携带有会话标识的第一交互请求。
56.s402，获取第一交互请求关联的访问页面地址。
57.s403，根据会话标识和访问页面地址，确定会话标识关联的访问路径。
58.s404，响应于获取到业务端向用户端反馈的第一订单信息，提取第一订单的订单标识和下单请求的会话标识。
59.其中，业务端可以是产品业务方对应的系统，可以是每个产品对应的一个业务系统，也可以是同类别的产品对应一个业务系统。第一订单信息是业务端响应用户端发送的下单请求生成。
60.可选的，用户在用户端下单后，用户端会生成下单请求，并通过数据处理系统将该下单请求转送至业务端，由业务端响应该下单请求生成订单信息，即第一订单信息。并将该第一订单信息通过数据处理系统反馈给用户端进行确认及付款等操作。也就是说，数据处理系统在向用户端转发第一订单信息时，能够监测到该第一订单信息，该第一订单信息中可以包括但不限于：当前订单(即第一订单)的订单标识和下单请求中携带的会话标识等，在本实施例中，从订单信息中至少提取出第一订单的订单标识和下单请求的会话标识。
61.需要说明的是，第一订单信息中的会话标识是从下单请求中提取的。
62.s405，建立第一订单的订单标识和下单请求的会话标识间的关联关系。
63.可选的，本实施例可以按照一定的索引方式(如键值对的索引方式)，建立第一订单的订单标识和下单请求的会话标识间的关联关系。并将该关联关系存储在本地数据库中，以便于后续查找。
64.需要说明的是，本公开实施例中，与该下单请求的会话标识具有关联关系的订单标识不一定是唯一的，例如，在预设时间段内，用户端购买了数据处理系统的2个产品，则这两个产品的订单标识关联的都是表征这段时间内用户端与数据处理系统交互的同一个会话标识。另外，还需要说明的是，若数据处理系统的产品是不同业务端(如服装类产品的业务方和电子类产品的业务端)的多个产品，则还可能存在同一个会话标识关联不通过业务端的不同产品的订单标识。
65.s406，响应于接收到订单信息处理请求，确定待处理订单的订单标识。
66.其中，订单信息处理请求可以是具有产品订单关联的访问路径分析需求的一方(如负责产品销售的业务端)向数据处理系统发起的。该订单信息处理请求中至少包含对待处理订单的描述信息，如可以是待处理订单的产品名称、待处理订单的订单标识和待处理订单的下单用户身份等中的至少一项。对此本实例不进行限定。订单标识可以是产品订单的唯一性标识，可以是订单系统在生成订单时确定的。
67.可选的，在本实施例中，数据处理系统响应接收到的订单信息处理请求，若该订单信息处理请求中包含有待处理订单的订单标识，则此时可以直接从订单信息处理请求中提取出待处理订单的订单标识。若不包含，则需要基于订单信息处理请求中包含的待处理订单的描述信息，如待处理订单的产品名称或下单用户身份等，与订单系统进行交互，来获取待处理订单的描述信息对应的待处理订单的订单标识。可选的，若数据处理系统本地存储有产品订单的订单信息，则还可以从本地存储的产品订单的订单信息中查找出符合待处理订单的描述信息的产品作为本次待处理产品，进而从待处理产品的订单信息中获取待处理产品的订单标识。
68.s407，根据待处理订单的订单标识，以及订单标识与会话标识间的关联关系，确定待处理订单的会话标识。
69.可选的，本实施例可以是从s405建立的所有订单标识与会话标识间的关联关系中，查找待处理订单的订单标识关联的会话标识，作为待处理订单的会话标识。
70.s408，根据待处理订单的会话标识关联的访问路径，确定待处理订单的生成信息。
71.其中，本实施例的生成信息可以是与待处理订单的会话标识关联的访问路径相关联的信息。例如，可以是确定待处理订单对应的产品下单来源。即用户通过哪种来源了解到该产品。可选的，下单来源包括但不限于：自然搜索、内部导流、外部合作、定期宣传以及用户收藏等。
72.可选的，本实施例可以是在s403确定的所有会话标识关联的访问路径中，查找待处理订单的会话标识关联的访问路径，作为待处理访问路径，在根据待处理访问路径，确定待处理订单的生成信息时，可以是将访问路径的源头地址，或源头地址对应的站点作为该生成信息。例如，若待处理访问路径的源头地址是浏览器搜索引擎的地址，则可以将该浏览器搜索引擎的地址作为待处理订单的生成信息；也可以将该浏览器搜索引擎的地址对应的站点(如某搜索引擎)作为待处理订单的生成信息。
73.在根据待处理访问路径，确定待处理订单的生成信息时，还可以是分析待处理路径的包含的各访问页面地址对应的至少一个站点，然后统计所述至少一个站点对应的访问页面地址的数量，将出现频次最高的站点作为待处理订单的生成信息等。本实施例还可以采用其他方式确定，对此不进行限定。
74.本公开实施例的方案，基于业务端向用户端反馈的第一订单信息，提取订单标识和会话标识，并建立两者之间的关联关系。本实施例，仅通过订单信息即可建立订单标识和会话标识间的关联关系，极大的简化了关联关系建立过程的复杂度。另外，本实施例在确定待处理订单的订单标识后，基于预先建立的订单标识与会话标识间的关联关系，以及会话标识关联的访问路径，即可快速生成于访问路径关联的订单的生成信息。且由于本实施例中的会话标识携带在交互请求中，稳定性好，不易丢失。可以很好的避免访问路径涉及多页面跳转时，存在会话标识关联的访问路径不完整的情况，保证了待处理订单的访问路径的完整性，进而提高了基于该访问路径确定的生成信息的精准性。
75.进一步的，在本公开实施例中，提取第一订单的订单标识和下单请求的会话标识，包括：通过配置在下单接口处的追踪插件，提取第一订单的订单标识和下单请求的会话标识。具体的，本实施例中对需要确定产品生成信息的业务端，可以在产品下单接口处配置追踪插件，该插件用于从第一订单信息中提取第一订单的订单标识和该第一订单关联的下单
请求的会话标识。这样设置的好处是：对待进行数据处理的产品获取订单的订单标识和交互的会话标识，即只对待进行数据处理的产品，建立订单标识和会话标识间的关联关系，提高了关联关系建立的效率，避免了资源的浪费。此外，在对业务端的下单产品进行数据处理的过程中，不侵入业务端，且业务端零感知。
76.需要说明的是，上述实施例涉及的待处理订单为常规订单(即本实施例的第一订单)，该第一订单是指用户浏览产品页面后，直接在产品页面执行下单操作，而生成的订单。但是在产品实际销售过程中，还会存在另一种类型的订单，即非常规的定制订单(即本实施例的第二订单)，该第二订单是指用户浏览产品页面后，发现该产品不能满足自身的个性化需求，需要与业务端进行沟通，将自己的需求告知业务端，得到业务端的同意后，由业务端代其下单。针对第二订单，由于其是业务端代为下单，无需用户端发送下单请求，所以该第二订单的订单信息中没有携带会话标识，也就是说，数据处理系统无法根据第二订单的订单信息直接建立订单标识与会话标识间的关联关系。
77.图5是针对此类订单，提供的一种数据处理方法的流程图，本实施例在上述实施例的基础上，进一步给出了在待处理的订单为第二订单的情况下，如何确定待处理订单的生成信息的详细介绍。如图5所示，该方法可以包括：
78.s501，在数据已授权的情况下，获取携带有会话标识的第一交互请求。
79.s502，获取第一交互请求关联的访问页面地址。
80.s503，根据会话标识和访问页面地址，确定会话标识关联的访问路径。
81.s504，响应于获取到业务端向用户端反馈的第二订单信息，提取第二订单的订单标识和订单需求。
82.其中，所述第二订单信息是上述介绍的第二订单对应的信息。其是业务端根据用户端的订单需求生成。该第二订单信息中至少包含订单标识和订单需求。该订单需求可以是根据用户端发送的包含用户具体需求信息的沟通请求确定的，可以是用户具体需求信息，也可以是基于该具体需求信息编码得到的需求标识。该用户具体需求信息可以是用户关于下单产品的各性化定制需求，例如，若下单产品为一个水杯，则该沟通请求中包含的订单需求可以是在水平的杯盖上印上“张三”。
83.具体的，数据处理系统响应于获取到的业务端向用户端反馈的第二订单信息后，从该第二订单信息中提取第二订单的订单标识，以及该第二订单的订单需求。
84.s505，建立订单标识和订单需求间的关联关系。
85.可选的，本实施例可以按照一定的索引方式(如键值对的索引方式)，建立订单标识和订单需求间的关联关系。并将该关联关系存储在本地数据库中，以便于后续查找。
86.s506，获取用户端发送的包含订单需求的沟通请求。
87.可选的，用户端向业务端发送的沟通请求时，先将沟通请求发送至数据处理系统，由数据处理系统转发给业务端，因此，数据处理系统可以拦截并获取到用户端向业务端发送的包含订单需求沟通请求。由于该沟通需求属于用户端与数据处理系统间的交互请求，所以该沟通需求中携带有会话标识。
88.s507，建立沟通请求的会话标识与订单需求间的关联关系。
89.可选的，从获取的沟通请求中提取会话标识和订单需求，并按照一定的索引方式(如键值对的索引方式)，建立会话标识和订单需求间的关联关系。并将该关联关系存储在
本地数据库中，以便于后续查找。
90.s508，响应于接收到订单信息处理请求，确定待处理订单的订单标识。
91.s509，根据待处理订单的订单标识，以及订单标识与会话标识间的关联关系，确定待处理订单的会话标识。
92.具体的，本实例可以是先从s505建立的所有订单标识与订单需求间的关联关系中，查找待处理订单的订单标识对应的订单需求，作为待处理订单的订单需求；再从s507建立的所有订单需求与会话标识间的关联关系中，查找待处理订单的订单需求对应的会话标识，作为待处理订单的会话标识。
93.s510，根据待处理订单的会话标识关联的访问路径，确定待处理订单的生成信息。
94.本公开实施例的方案，对于非常规的定制订单，即第二订单，可以间接建立会话标识与订单标识间关联关系，即建立订单标识与需求标识间的关联关系，以及需求标识和会话标识间的关联关系。从而实现在待处理的订单为第二订单的情况下，也能够准确确定待处理订单的生成信息。提高了订单生成信息确定的灵活性和通用性。
95.图6是根据本公开实施例提供的多方交互实现数据处理的流程示意图。如图6所示，本实施例的数据处理系统可以进一步包括：产品控制中台、会话管理系统和流量追踪系统；除此之外，参与方还包括：用户端、业务端系统和订单系统。
96.其中，用户端可以是订单处理的前端，例如，可以是用户所在设备上的应用程序端，也可以是用户所在设备的浏览器端。用户通过该用户端与产品控制中台交互，产品控制中台是连接用户端与业务端系统的桥梁，也就是说用户端可以通过该产品控制中台与多个不同的业务端系统进行交互。业务端系统是产品业务端管理其产品的系统，该业务端系统在用户下单(即收到下单请求)时与订单系统交互。订单系统管理所有业务端的产品的订单情况。流量追踪系统是执行订单信息处理，确定待处理订单的生成信息的系统，该流量追踪系统、会话管理系统和产品控制中台可以部署在一个电子设备中，也可以分类部署在多个电子设备中。会话管理系统是用于管理用户端与产品控制中台的交互情况的系统，其中记录有每次交互的会话标识关联的访问路径。具体的，如图6所示，本实施例对于一个第一订单从下单到确定生成信息的整个流程包括：
97.用户通过用户端下单，即生成下单请求发送至产品控制中台，产品控制中台会转发该下单请求至当前下单产品对应的业务端系统，该业务端系统会将该下单请求发送至订单系统，以完成实际下单，订单系统响应该下单请求生成订单信息，反馈给业务端系统，业务端系统再通过产品控制中台回传给用户端。
98.在产品控制中台回传订单信息给用户端的过程中，产品控制平台会截取回传的订单信息，并从中截取订单标识和会话标识，发送至流量追踪系统进行关联存储。可选的，该会话标识还可以从该订单信息对应的下单请求中提取。另外，本实施例还可以截取订单的交易信息，并将其与订单标识关联后发送至流量追踪系统存储。流量追踪系统在成功接收产品控制中台发送的信息后，会向其反馈回传成功的消息。
99.流量追踪系统在存储了订单标识后，会基于该订单标识定时轮询该订单是否关闭，若没有，则基于该订单的订单标识与订单系统交互，获取该订单最新的交易信息，并基于此来更新本地存储的该订单的交易信息。
100.当流量追踪系统接收到订单信息处理请求后，会响应于订单信息处理请求，确定
待处理订单的订单标识，然后根据待处理订单的订单标识，以及本地存储的订单标识和会话标识间的关联关系，确定待处理订单的会话标识，并基于待处理订单的会话标识，从会话管理系统中存储的所有会话标识关联的访问路径中，查找待处理订单的会话标识关联的访问路径，进而根据该访问路径，确定待处理订单的生成信息。
101.本实施例的方案，执行数据处理流程时利用的各数据处理端可以是现有的，各业务端想要确定订单的生成信息时，只需在产品控制中台侧嵌入能够提取订单标识和会话标识的监测组件，以建立会话标识与订单标识间的关联关系，以及控制产品控制中台将与访问路径关联的会话标识携带在交互请求中，再结合已有会话管理系统中存储的会话标识关联的访问路径，即可实现确定订单的生成信息。具有成本低、通用性强和快速上线的能力。另外，由于本实施例对不同产品业务端的产品使用统一规则进行统计，具有跨产品线统计能力。
102.图7是根据本公开实施例提供的一种数据处理装置的结构示意图。本公开实施例适用于如何生成用户访问页面的访问路径的情况，该装置可以采用软件和/或硬件来实现，该装置可以实现本公开任意实施例所述的数据处理方法。如图7所示，该数据处理装置包括：
103.请求获取模块701，用于在数据已授权的情况下，获取携带有会话标识的第一交互请求；
104.页面地址获取模块702，用于获取所述第一交互请求关联的访问页面地址；
105.访问路径确定模块703，用于根据所述会话标识和所述访问页面地址，确定所述会话标识关联的访问路径。
106.本实施例的方案，通过获取携带有会话标识的第一交互请求，以及该第一交互请求的访问页面地址，基于该会话标识和访问页面地址，生成该会话标识关联的访问路径。本实施例中，访问路径关联的会话标识是从交互请求中获取的，而非从访问页面地址中提取。由于访问页面的地址在多页面跳转的过程中，容易丢失标识，所以本实施例从交互请求中提取的会话标识的稳定性更好，进而基于该会话标识关联的访问页面地址更全面，即生成的该会话标识的访问路径更完整。
107.进一步的，上述访问路径确定模块703具体用于：
108.按照第二交互请求的发起时间的顺序，将所述访问页面地址串联，得到所述会话标识关联的访问路径；其中，所述第二交互请求为携带有同一会话标识的第一交互请求。
109.进一步的，上述访问路径确定模块703还具体用于：
110.获取所述会话标识已关联的访问路径；
111.根据所述访问页面地址，更新所述会话标识已关联的访问路径。
112.进一步的，上述数据处理装置，还包括：
113.会话标识添加模块，用于响应于获取到用户端执行交互请求生成操作，且在预设时段内，所述用户端已执行过交互请求生成操作，则获取所述用户端在所述预设时段的会话标识，并将所述会话标识添加到所述用户端当前生成的交互请求中。
114.进一步的，上述数据处理装置，还包括：
115.订单标识确定模块，用于响应于接收到订单信息处理请求，确定待处理订单的订单标识；
116.会话标识确定模块，用于根据所述待处理订单的订单标识，以及订单标识与会话标识间的关联关系，确定待处理订单的会话标识；
117.生成信息确定模块，用于根据所述待处理订单的会话标识关联的访问路径，确定所述待处理订单的生成信息。
118.进一步的，上述数据处理装置，还包括：
119.第一标识提取模块，用于响应于获取到业务端向用户端反馈的第一订单信息，提取第一订单的订单标识和下单请求的会话标识；其中，所述第一订单信息是所述业务端响应所述用户端发送的所述下单请求生成；
120.第一关系建立模块，用于建立所述第一订单的订单标识和所述下单请求的会话标识间的关联关系。
121.进一步的，上述标识提取模块具体用于：
122.通过配置在下单接口处的追踪插件，提取第一订单的订单标识和所述下单请求的会话标识。
123.进一步的，上述数据处理装置，还包括：
124.第二标识提取模块，用于响应于获取到业务端向用户端反馈的第二订单信息，提取第二订单的订单标识和订单需求；其中，所述第二订单信息是所述业务端根据所述用户端的订单需求生成；
125.第二关系建立模块，用于建立所述订单标识和所述订单需求间的关联关系；
126.所述请求获取模块，还用于获取所述用户端发送的包含所述订单需求的沟通请求；
127.第三关系建立模块，用于建立所述沟通请求的会话标识与所述订单需求间的关联关系。
128.上述产品可执行本公开任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。
129.本公开的技术方案中，所涉及的订单信息(比如订单标识、会话标识、访问路径、订单需求，以及交易信息等)的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。
130.根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
131.图8示出了可以用来实施本公开的实施例的示例电子设备800的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字助理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
132.如图8所示，设备800包括计算单元801，其可以根据存储在只读存储器(rom)802中的计算机程序或者从存储单元808加载到随机访问存储器(ram)803中的计算机程序，来执行各种适当的动作和处理。在ram 803中，还可存储设备800操作所需的各种程序和数据。计算单元801、rom 802以及ram 803通过总线804彼此相连。输入/输出(i/o)接口805也连接至
总线804。
133.设备800中的多个部件连接至i/o接口805，包括：输入单元806，例如键盘、鼠标等；输出单元807，例如各种类型的显示器、扬声器等；存储单元808，例如磁盘、光盘等；以及通信单元809，例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
134.计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理，例如数据处理方法。例如，在一些实施例中，数据处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元808。在一些实施例中，计算机程序的部分或者全部可以经由rom 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序加载到ram 803并由计算单元801执行时，可以执行上文描述的数据处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元801可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据处理方法。
135.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
136.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
137.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
138.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来
将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
139.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)、区块链网络和互联网。
140.计算机系统可以包括用户端和服务器。用户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有用户端-服务器关系的计算机程序来产生用户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与vps服务中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。
141.人工智能是研究使计算机来模拟人的某些思维过程和智能行为(如学习、推理、思考、规划等)的学科，既有硬件层面的技术也有软件层面的技术。人工智能硬件技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理等技术；人工智能软件技术主要包括计算机视觉技术、语音识别技术、自然语言处理技术及机器学习/深度学习技术、大数据处理技术、知识图谱技术等几大方向。
142.云计算(cloud computing)，指的是通过网络接入弹性可扩展的共享物理或虚拟资源池，资源可以包括服务器、操作系统、网络、软件、应用和存储设备等，并可以按需、自服务的方式对资源进行部署和管理的技术体系。通过云计算技术，可以为人工智能、区块链等技术应用、模型训练提供高效强大的数据处理能力。
143.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
144.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。