An AI-based e-commerce information push method

Abstract

This invention relates to the field of e-commerce information processing and discloses an artificial intelligence-based e-commerce information push method. The method acquires behavioral event data of a target user within the current session window and determines the current transaction status through a state recognition model. While generating candidate push information, a snapshot is simultaneously generated, and the state version number at the time of generation is compared with the current state version number before sending. When the status changes, an intent drift value is generated based on the current transaction status, the original push intent, and historical push feedback data, and the candidate push information is marked as pending verification, frozen, or invalid accordingly. A push relationship graph is then established for the push information to be verified, and the target push information is determined by combining state conflicts, mutual exclusion relationships, and channel load. This method can reduce expired, duplicate, and conflicting pushes entering the user terminal.

Description

Technical Field

[0001] This invention relates to the field of e-commerce information processing, and more specifically to an e-commerce information push method based on artificial intelligence. Background Technology

[0002] E-commerce platforms typically generate candidate push notifications based on users' search history, browsing history, add-to-cart history, order history, and product popularity, and send them to users' devices through channels such as in-app messages, application notifications, SMS, or email. With the application of artificial intelligence models in e-commerce platforms, existing push methods can sort and send information such as product promotions, price reduction reminders, discount reminders, order encouragement, and repeat purchase reminders based on user profiles, product profiles, or real-time behavior prediction results.

[0003] However, in actual push notifications, users' transaction status often exhibits short-term fluctuations. For example, a user might place an order, cancel an order, request a refund, turn off push notifications, or unsubscribe from push notifications shortly after a candidate push notification is generated. At this point, candidate push notifications already in the push queue may still be sent based on the user's status at the time of generation. This could result in users receiving the same product promotional information even after a purchase, receiving similar marketing information after entering the after-sales stage, or receiving push notifications of the same category even after explicitly rejecting them.

[0004] Existing technologies primarily focus on improving product matching accuracy, click-through rate prediction accuracy, or user profile accuracy, while paying insufficient attention to the status changes of candidate push information from its generation to its actual delivery. If push tasks lack pre-delivery validity checks, freeze processing, invalidation handling, and conflict filtering, expired, duplicate, or inconsistent push information can easily continue to occupy the push queue and message channel, eventually reaching the user's terminal. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides an artificial intelligence-based e-commerce information push method to solve the technical problems existing in the prior art.

[0006] The above-mentioned technical objective of the present invention is achieved through the following technical solution: An AI-based e-commerce information push method includes the following steps: S1: Obtain behavioral event data generated by the target user in the current session window, convert the behavioral event data into event feature records, and input the event feature records arranged according to the occurrence time into the status recognition model to obtain the current transaction status of the target user; S2: When generating candidate push information, a snapshot is generated for the task of generating the candidate push information. The task snapshot includes the original push intent, triggering event, product category code, product identifier, transaction status at the time of generation, status version number at the time of generation, and valid deadline. S3: When a key behavioral event is detected in the target user, the current transaction status is updated according to the key behavioral event, and the current status version number corresponding to the current transaction status is updated. The key behavioral events include order placement event, order cancellation event, refund event, push notification closure event, and push notification unsubscription event. S4: Before sending the candidate push information, read the task generation snapshot corresponding to the candidate push information, compare the status version number at the time of generation with the current status version number, and compare the current time with the valid deadline; S5: When the current time is later than the effective deadline, the candidate push information is marked as invalid push information and transferred to the invalid push queue; S6: When the generated state version number is inconsistent with the current state version number, and the current time is not later than the effective deadline, generate the intent drift value corresponding to the candidate push information based on the current transaction status, the original push intent, the product category code, the state change time, the transaction behavior time sequence characteristics, and the push rejection behavior time sequence characteristics. The intent drift value includes active rejection drift results and passive scenario drift results. The active rejection drift results are determined based on push notification closing events, ignore events, and unsubscribe events. The passive scenario drift results are determined based on order placement events, order cancellation events, refund events, and status change times. S7: Based on the intent drift value, mark the candidate push information as push information to be verified, frozen push information, or invalid push information, wherein the frozen push information is transferred to the frozen push queue and waits for re-verification, and the invalid push information is transferred to the invalid push queue and stops sending. S8: Establish a push relationship graph for the push information to be verified. The nodes in the push relationship graph are the push information to be verified. The edges in the push relationship graph include state conflict edges and mutual exclusion edges. The state conflict edges are determined based on the conflict relationship between the original push intention of the push information to be verified and the current transaction status. The mutual exclusion edges are determined based on the product duplication relationship, equity duplication relationship, push channel duplication relationship and time window conflict relationship between the two push information to be verified. S9: Based on the push relationship graph and the current push channel load, determine the target push information from the push information to be verified that has never had a state conflict edge, and send the target push information to the target user's terminal.

[0007] Preferably, the event feature record includes event type code, product category code, product identifier, price range code, event occurrence time, session identifier, and push channel identifier; The current session window is bounded by the session identifier, starting at the moment the session is established when the target user enters the e-commerce platform, and ending at the moment the target user exits the e-commerce platform, the moment the target user completes order payment, the moment the target user generates an unsubscribe push event, or the moment when no new behavioral event data is generated for 30 consecutive minutes.

[0008] Preferably, the status recognition model takes event feature records arranged according to the occurrence time as input and takes browsing status, price comparison status, pending transaction status, completed transaction status, after-sales status, or refused contact status as output. When the most recent key behavioral event in the behavioral event data is an order placement event, and there are no order cancellation events or refund events after the order placement event, the current transaction status is determined to be a completed status; When the most recent key behavioral event in the behavioral event data is a refund event, the current transaction status is determined to be an after-sales status; when there is an unsubscribe push event in the behavioral event data, the current transaction status is determined to be a refused-reach status.

[0009] Preferably, the current status version number is recorded independently under each session identifier of the target user; When an order placement event, order cancellation event, refund event, push notification shutdown event, or push notification unsubscription event is detected, the e-commerce platform server increments the current status version number by one. When a search event, product details browsing event, similar product comparison event, or add-to-cart event is detected, the current state version number remains unchanged.

[0010] Preferably, the original push intent includes product promotion intent, price reduction reminder intent, discount reminder intent, order promotion intent, after-sales service intent, and repeat purchase reminder intent; The triggering event is the behavioral event data on which the candidate push information is generated; The effective deadline is determined based on the original push intention and the triggering event, and is stored in correspondence with the task identifier of the candidate push information.

[0011] Preferably, when generating the intent drift value, the e-commerce platform server determines the category drift amount, stage drift amount, and negative feedback drift amount respectively; The category drift amount is determined based on the category difference between the product category code corresponding to the current transaction status and the product category code in the task-generated snapshot; The stage drift amount is determined based on the correspondence between the current transaction status and the original push intent in the status intent conflict table; The negative feedback drift amount is determined based on the number of times the target user closes, ignores, and unsubscribes from push notifications for the same product category in the current session window and within the 24 hours prior to the start of the current session window.

[0012] Preferably, the product category code corresponding to the current transaction status is determined based on the most recent behavioral event data that triggered the current transaction status; When the current transaction status is browsing, comparing prices, or pending transaction, take the product category code from the most recent product details browsing event, similar product comparison event, or added to cart event; When the current transaction status is "completed", take the product category code of the product corresponding to the most recent order event; When the current transaction status is after-sales, take the product category code of the order corresponding to the most recent refund event; When the current transaction status is "rejected", take the product category code from the push information corresponding to the most recent close push event or unsubscribe push event.

[0013] Preferably, the state intent conflict table includes the correspondence between the current transaction state, the original push intent, and the stage drift amount; When the current transaction status is "completed" and the original push intention is the same product promotion intention, the same product price reduction reminder intention, or the same order promotion intention, the candidate push information is determined to have stage drift. When the current transaction status is after-sales status, and the original push intention is product promotion intention or repurchase reminder intention, the candidate push information is determined to have stage drift; When the current transaction status is a denied access status, and the original push intent is a product promotion intent, price reduction reminder intent, discount reminder intent, order promotion intent, or repeat purchase reminder intent, the candidate push information is determined to have stage drift. The same product can be identified by the consistency of its product label.

[0014] Preferably, the e-commerce platform server stores a freeze threshold and an invalidation threshold, and the invalidation threshold is greater than the freeze threshold; When the intent drift value is less than the freeze threshold, the candidate push information is marked as push information to be verified. When the intent drift value is greater than or equal to the freeze threshold and less than the failure threshold, the candidate push information is marked as frozen push information; When the intent drift value is greater than or equal to the failure threshold, the candidate push information is marked as failed push information; The freezing threshold and the failure threshold are determined based on historical push logs, which include the generation time of candidate push information, sending time, target user transaction status change time, push closing event, push unsubscription event, and order status change result.

[0015] Preferably, when the freeze push information is transferred to the freeze push queue, the e-commerce platform server records the reason for the freeze and the re-verification time; When the re-verification time is reached, the e-commerce platform server rereads the task generation snapshot corresponding to the frozen push information, and re-executes the comparison between the state version number at the time of generation and the current state version number, as well as the generation of the intent drift value. If the regenerated intent drift value is less than the freezing threshold, the frozen push information is converted into push information to be verified. If the regenerated intent drift value is greater than or equal to the failure threshold, the frozen push information is transferred to the failure push queue. If the regenerated intent drift value is greater than or equal to the freeze threshold and less than the failure threshold, the frozen push information is kept in the frozen push queue and the re-verification time is re-determined. When generating the intent drift value, the e-commerce platform server determines the dynamic drift weight based on the transaction behavior timing characteristics and the push rejection behavior timing characteristics; The transaction behavior timing characteristics include the chronological relationship between the order placement event, order cancellation event, refund event and the generation time of candidate push information; the push rejection behavior timing characteristics include the chronological relationship between the push closing event, ignore event, unsubscribe event and the generation time of candidate push information. The e-commerce platform server adjusts the proportions of category drift, stage drift, and negative feedback drift in the intent drift value according to the dynamic drift weights. The e-commerce platform server determines the state timing decay coefficient based on the time interval between the state change time and the candidate push information sending verification time. As the time interval increases, the impact of stage drift caused by passive scene drift is reduced; When a target user generates a push notification close event or unsubscribe event within the time interval, the negative feedback drift effect generated by the active rejection drift is maintained.

[0016] In summary, the present invention has the following main beneficial effects: This application achieves pre-send verification of push task validity by synchronously recording a task generation snapshot during the generation of candidate push information and comparing the status version number at the time of generation with the current status version number before sending the candidate push information. Specifically, the task generation snapshot records the original push intent, triggering event, product category code, product identifier, transaction status at generation, status version number at generation, and valid deadline. When a target user performs key actions such as placing an order, canceling an order, requesting a refund, closing or unsubscribing from push notifications after the candidate push information is generated, the server can identify that the user's transaction status has undergone a critical change through the change in the status version number, preventing the candidate push information from entering the sending process with the old status at the time of generation. Thus, candidate push information that has exceeded the valid deadline can be directly placed into the invalid push queue, and candidate push information that deviates from the current transaction status can enter the subsequent intent drift judgment process, reducing the situation of continuing to push the same product promotion information after a transaction has been completed, continuing to push similar marketing information during the after-sales stage, and continuing to send marketing information after being rejected.

[0017] This application generates an intent drift value based on the current transaction status, original push intent, product category code, and historical push feedback data. Combined with freeze and invalidation thresholds, it categorizes candidate push information into push information awaiting verification, frozen push information, and invalid push information, achieving a hierarchical flow control effect for candidate push tasks. Specifically, the category drift reflects the deviation between the product category corresponding to the current transaction status and the product category of the candidate push information; the stage drift reflects the conflict between the current transaction status and the original push intent; and the negative feedback drift reflects the target user's closing, ignoring, and unsubscribing status of push information for the same product category. Through this multi-dimensional judgment, candidate push information with slight deviations but still potentially recoverable validity can be placed in the frozen push queue and re-judged after the re-verification time expires; candidate push information that clearly conflicts with the current transaction status is placed in the invalid push queue and stopped from being sent. This avoids simply deleting push tasks that may still have sending value, while also preventing invalid tasks from continuing to occupy push queue resources.

[0018] This application establishes a push relationship graph for push information to be verified and determines the target push information based on state conflict edges, mutual exclusion edges, and the current push channel load, thereby reducing conflicting pushes, duplicate pushes, and channel congestion. Specifically, state conflict edges are used to identify the conflict between the original push intention of the push information to be verified and the current transaction state, while mutual exclusion edges are used to identify duplicate product, duplicate rights, duplicate push channels, and time window conflicts among different push information to be verified. Before determining the target push information, the server first deletes push information to be verified with state conflict edges, and then retains push information that matches the current transaction state and has a more recent generation time from the push information to be verified with mutual exclusion edges. It then determines whether to send immediately, send delayed, or merge the push information based on the current push queue length, the number of pushes already received by the target user, and the number of pushes sent through the push channel. This reduces the number of substantially identical or conflicting push information received by the same user within a short period, and reduces the occupation of the terminal and server push channels by invalid pushes. Attached Figure Description

[0019] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Example 1 refer to Figure 1 An AI-based e-commerce information push method includes the following steps: S1: Obtain behavioral event data generated by the target user in the current session window, convert the behavioral event data into event feature records, and input the event feature records arranged according to the occurrence time into the status recognition model to obtain the current transaction status of the target user; S2: When generating candidate push information, a snapshot is generated for the task of generating the candidate push information. The task snapshot includes the original push intent, triggering event, product category code, product identifier, transaction status at the time of generation, status version number at the time of generation, and valid deadline. S3: When a key behavioral event is detected in the target user, the current transaction status is updated according to the key behavioral event, and the current status version number corresponding to the current transaction status is updated. The key behavioral events include order placement event, order cancellation event, refund event, push notification closure event, and push notification unsubscription event. S4: Before sending the candidate push information, read the task generation snapshot corresponding to the candidate push information, compare the status version number at the time of generation with the current status version number, and compare the current time with the valid deadline; S5: When the current time is later than the effective deadline, the candidate push information is marked as invalid push information and transferred to the invalid push queue; S6: When the generated state version number is inconsistent with the current state version number, and the current time is not later than the effective deadline, generate the intent drift value corresponding to the candidate push information based on the current transaction status, the original push intent, the product category code, the state change time, the transaction behavior time sequence characteristics, and the push rejection behavior time sequence characteristics. The intent drift value includes active rejection drift results and passive scenario drift results. The active rejection drift results are determined based on push notification closing events, ignore events, and unsubscribe events. The passive scenario drift results are determined based on order placement events, order cancellation events, refund events, and status change times. S7: Based on the intent drift value, mark the candidate push information as push information to be verified, frozen push information, or invalid push information, wherein the frozen push information is transferred to the frozen push queue and waits for re-verification, and the invalid push information is transferred to the invalid push queue and stops sending. S8: Establish a push relationship graph for the push information to be verified. The nodes in the push relationship graph are the push information to be verified. The edges in the push relationship graph include state conflict edges and mutual exclusion edges. The state conflict edges are determined based on the conflict relationship between the original push intention of the push information to be verified and the current transaction status. The mutual exclusion edges are determined based on the product duplication relationship, equity duplication relationship, push channel duplication relationship and time window conflict relationship between the two push information to be verified. S9: Based on the push relationship graph and the current push channel load, determine the target push information from the push information to be verified that has never had a state conflict edge, and send the target push information to the target user's terminal.

[0022] E-commerce platform servers identify the status of target users' behavioral event data, and before actually sending candidate push information, they perform status version number comparison, intent drift value calculation, frozen queue processing, invalid queue processing, and push relationship graph processing to determine whether to send the target push information.

[0023] In this embodiment, the e-commerce platform server can be either the business server of the e-commerce platform or a message push server connected to the business server. The target user's terminal can be a mobile phone, tablet computer, personal computer, or other terminal capable of accessing the e-commerce platform. The e-commerce platform server and the target user's terminal transmit push information through in-application messaging channels, SMS channels, site messaging channels, email channels, or mini-program messaging channels.

[0024] The behavioral event data used in this embodiment comes from platform operation logs, order status logs, and push feedback logs recorded by the e-commerce platform within the scope of user authorization. Before entering this method, the behavioral event data undergoes identification processing, converting the user account into a target user identifier and the order number, product number, and push task number into internal platform codes. This method does not use facial information, biometric information, or precise geographic location as the basis for push notifications.

[0025] After a target user enters the e-commerce platform, the e-commerce platform server establishes a current session window and assigns a session identifier to the current session window. The current session window is bounded by the session identifier, starting from the moment the target user enters the e-commerce platform and ending at the moment the target user exits the e-commerce platform, the moment the target user completes order payment, the moment the target user generates an unsubscribe push event, or the moment no new behavioral event data is generated for thirty consecutive minutes.

[0026] Within the current session window, the e-commerce platform server collects behavioral event data generated by the target user. This behavioral event data includes search events, product detail browsing events, similar product comparison events, adding items to cart events, placing orders events, order cancellation events, refund events, disabling push notifications events, and unsubscribing from push notifications events.

[0027] Before being input into the state recognition model, behavioral event data is converted into event feature records. Each event feature record includes an event type code, a product category code, a product identifier, a price range code, the event occurrence time, a session identifier, and a push channel identifier.

[0028] The event type code distinguishes between search events, product detail browsing events, similar product comparison events, add-to-cart events, order placement events, order cancellation events, refund events, push notification cancellation events, and push notification unsubscription events. The product category code indicates the category position of the product associated with the behavioral event data within the e-commerce platform's product category system. The product identifier indicates the specific product associated with the behavioral event data. The price range code indicates the price range to which the product belongs; this price range is determined by the e-commerce platform server based on the platform's product price segmentation configuration table. The event occurrence time determines the chronological order of the behavioral event data within the current session window. The session identifier identifies a single, continuous access process by the target user. The push channel identifier indicates the push channel associated with the behavioral event data.

[0029] The e-commerce platform server sorts the event feature records according to the time of the event, forming an event feature record sequence, and uses the event feature record sequence as input to the state recognition model.

[0030] The e-commerce platform server is configured with a status recognition model. This model is a sequence classification model, comprising a feature embedding layer, a temporal feature extraction layer, and a status classification layer. The feature embedding layer converts event type codes, product category codes, product identifiers, price range codes, event occurrence time, session identifiers, and push channel identifiers into event vectors. The temporal feature extraction layer extracts the chronological relationships between event vectors based on their occurrence time. The status classification layer outputs the current transaction status of the target user.

[0031] The input to the status recognition model is a sequence of event feature records arranged according to the time of event occurrence, and the output is browsing status, price comparison status, pending transaction status, completed transaction status, after-sales status, or refused contact status.

[0032] The training data for the state recognition model comes from historical session logs, historical order status logs, and historical push feedback logs of the e-commerce platform. The input to the training samples is a sequence of event feature records from historical sessions. The labels for the training samples are determined based on historical order status and historical push feedback status. A session is labeled as "Browsing" when only search and product detail browsing events exist, and no "Add to Cart" or "Place Order" events occur. A session is labeled as "Price Comparison" when there are similar product comparison events or multiple similar product detail browsing events. A session is labeled as "Pending Order" when there is an "Add to Cart" event but no order placement event occurs. A session is labeled as "Completed" when there is an order placement event, and no order cancellation or refund events follow. A session is labeled as "After-Sales" when there is a refund event. A session is labeled as "Rejected Push Notification" when there is an unsubscribe push notification event.

[0033] After the status recognition model outputs the current transaction status, the e-commerce platform server performs status correction based on key behavioral events. If the most recent key behavioral event in the behavioral event data is an order placement event, and there are no subsequent order cancellation or refund events, the current transaction status is determined to be a completed transaction. If the most recent key behavioral event in the behavioral event data is a refund event, the current transaction status is determined to be an after-sales status. If there is an unsubscribe push notification event in the behavioral event data, the current transaction status is determined to be a denied notification status.

[0034] The current transaction status is used to determine whether candidate push information that has entered the push process is still suitable for sending before it is sent, and is not used as a simple user interest tag.

[0035] The e-commerce platform server independently records the current status version number for each target user under each session identifier. The current status version number is used to indicate the number of times the target user's transaction status has undergone critical changes within the current session window.

[0036] When the current session window is established, the e-commerce platform server initializes the current state version number under that session identifier to 0. When an order placement event, order cancellation event, refund event, push notification cancellation event, or push notification unsubscription event is detected, the e-commerce platform server updates the current transaction status based on the key behavioral event and increments the current state version number once. When a search event, product details browsing event, similar product comparison event, or add-to-cart event is detected, the current state version number remains unchanged.

[0037] The reason for adopting the above status version number rule is that search events, product detail browsing events, similar product comparison events, and add-to-cart events mainly reflect the target user's selection process, while order placement events, order cancellation events, refund events, push notification cancellation events, and push notification unsubscription events directly affect whether candidate push information is still suitable for sending. By incrementing the current status version number only when key behavioral events occur, redundant calculations and queue reordering caused by ordinary browsing behaviors can be reduced.

[0038] When generating candidate push notifications, the e-commerce platform server assigns a task identifier to each candidate notification and generates a snapshot of the task generation corresponding to that identifier. The candidate push notifications are not sent directly after generation; instead, they undergo a verification process before being sent.

[0039] The task-generated snapshot includes the original push intent, triggering event, product category code, product identifier, transaction status at the time of generation, status version number at the time of generation, and valid expiration time.

[0040] The original push intent indicates the purpose of the push notification when the candidate push message is generated, including product promotion intent, price reduction reminder intent, discount reminder intent, order promotion intent, after-sales service intent, and repeat purchase reminder intent. The triggering event is the behavioral event data used to generate the candidate push message. The product category code and product identifier record the product range corresponding to the candidate push message. The transaction status at generation time is the transaction status of the target user at the time the candidate push message is generated. The status version number at generation time is the current status version number recorded under this session identifier at the time the candidate push message is generated. The valid deadline indicates the deadline before the candidate push message is allowed to enter the sending verification process.

[0041] The effective deadline is determined based on the original push intent and triggering event, and is stored in relation to the task identifier of the candidate push information. For discount reminder intents, the effective deadline is the expiration time of the discount benefit; for order promotion intents, the effective deadline is the platform retention time for items in the shopping cart or pending orders; for price reduction reminder intents, the effective deadline is the end time of the price reduction activity; for after-sales service intents, the effective deadline is the processing period corresponding to the service prompt in the after-sales process; for repeat purchase reminder intents, the effective deadline is the reminder period configured by the e-commerce platform based on the product consumption cycle. All of the above effective deadlines are derived from existing business data or platform configuration tables of the e-commerce platform.

[0042] By generating snapshots through tasks, e-commerce platform servers can determine whether the transaction status on which the candidate push information was based and the current transaction status have undergone critical changes before the candidate push information is actually sent.

[0043] Before sending candidate push information, the e-commerce platform server reads the task corresponding to the candidate push information to generate a snapshot and performs pre-send verification.

[0044] First, the e-commerce platform server compares the current time with the valid deadline in the task generation snapshot. If the current time is later than the valid deadline, the candidate push message is marked as invalid and moved to the invalid push queue, and sending is stopped.

[0045] Secondly, provided the current time is not later than the valid deadline, the e-commerce platform server compares the status version number at the time of task generation in the snapshot with the current status version number. If the status version number at the time of generation matches the current status version number, it means that no key behavioral event causing a change in the status version number has occurred since the candidate push information was generated. The candidate push information is then marked as push information to be verified and enters the subsequent push relationship graph processing.

[0046] If the version number generated at the time of creation is inconsistent with the current version number, it indicates that after the candidate push information was generated, the target user experienced one of the following events: placing an order, canceling an order, requesting a refund, turning off push notifications, or unsubscribing from push notifications. The candidate push information may have deviated from the current transaction state. In this case, the e-commerce platform server matches the current transaction state with the original push intent in the task generation snapshot to obtain the intent drift value corresponding to the candidate push information.

[0047] The intent drift value is used to characterize the degree of deviation between the generated candidate push information and the target user's current transaction state. The intent drift value is not calculated directly using fixed weights, but is dynamically determined by the e-commerce platform server based on the temporal characteristics of the target user's transaction behavior and push rejection behavior within the current session window.

[0048] Transaction behavior time-series features are used to represent the chronological relationship between order placement, order cancellation, refund events, and the generation time of candidate push notifications. Push rejection behavior time-series features are used to represent the chronological relationship between push notification closing, ignoring, and unsubscribing events and the generation time of candidate push notifications. The e-commerce platform server generates passive scenario drift results and active rejection drift results based on the transaction behavior time-series features and push rejection behavior time-series features, respectively.

[0049] When a status version number change is triggered by an order placement event, order cancellation event, or refund event, the e-commerce platform server enters passive scenario drift calculation logic. Passive scenario drift is used to determine whether candidate push information is no longer suitable for sending due to a change in the target user's natural transaction status. For example, if the target user has already placed an order and paid, candidate push information corresponding to product promotion intentions, price reduction reminder intentions, or order promotion intentions for the same product is no longer suitable for sending; if the target user has entered a refund state, candidate push information corresponding to product promotion intentions or repeat purchase reminder intentions for similar products is no longer suitable for sending.

[0050] The passive scene drift weight is determined based on the state temporal decay coefficient. The passive scene drift weight is determined according to the following formula: ; in, For passive scene drift weights, As the initial weights for passive scene drift, This is the time-series decay coefficient. This refers to the time interval between the status change time and the candidate push notification sending verification time. The status change time is the time when an order placement event, order cancellation event, or refund event triggers a change in the current status version number. The candidate push notification sending verification time is the time it takes for the e-commerce platform server to read the task, generate a snapshot, and perform pre-send verification. Through this method, the longer the time since the status change, the less impact the passive scenario drift caused by natural transaction status changes will have.

[0051] When a status version number change is triggered by a push notification closing event, an ignore event, or an unsubscribe event, the e-commerce platform server enters the active rejection drift calculation logic. Active rejection drift is used to determine whether the target user has already shown a tendency to refuse to be reached for the same product category or the same push notification channel. Active rejection drift is not processed according to the natural decay of normal transaction status, but is re-verified after the target user reopens the push notification channel, enters a new session window, or actively browses similar products.

[0052] The active rejection drift weight is determined based on the strength of the rejection behavior. The active rejection drift weight is determined according to the following formula: ; in, To actively reject drift weights, To actively reject drift initial weights, To disable push event count, To ignore the number of events, Mark the unsubscribe push event. , , This is a rejection weight coefficient generated by the e-commerce platform server based on historical push notification logs. It is applied when a target user unsubscribes from push notifications. Set to 1; if no unsubscribe push event is generated, Set to 0. Number of times push events are turned off. Number of ignored events The statistics are based on the current session window and the push information of the same product category within the 24 hours prior to the start of the current session window.

[0053] The e-commerce platform server generates the intent drift value of candidate push information based on passive scenario drift weight, active rejection drift weight, category drift amount, stage drift amount, and negative feedback drift amount. Specifically, the category drift amount is determined by the difference between the product category code corresponding to the current transaction state and the product category code in the task-generated snapshot; the stage drift amount is determined by the correspondence between the current transaction state and the original push intent in the state intent conflict table; and the negative feedback drift amount is determined by the number of times the target user closes, ignores, and unsubscribes from push information for the same product category in the current session window and the 24 hours prior to the start of the current session window.

[0054] The product category code corresponding to the current transaction status is determined based on the most recent behavioral event data that triggered the current transaction status. When the current transaction status is browsing, comparing prices, or pending transaction, the product category code is taken from the most recent product details browsing event, similar product comparison event, or add to cart event; when the current transaction status is completed, the product category code is taken from the order corresponding to the most recent order event; when the current transaction status is after-sales, the product category code is taken from the order corresponding to the most recent refund event; when the current transaction status is refused push notification, the product category code is taken from the push notification information corresponding to the most recent close push notification event or unsubscribe push notification event.

[0055] When the product category code corresponding to the current transaction status is the same as the product category code in the snapshot generated by the task, the category drift value is taken as the lower value; when they belong to the same first-level category but different second-level categories, the category drift value is taken as the middle value; when they belong to different first-level categories, the category drift value is taken as the higher value. The first-level and second-level categories come from the existing product category system of the e-commerce platform.

[0056] The stage drift amount is determined based on the status intent conflict table. The status intent conflict table includes the correspondence between the current transaction status, the original push intent, and the stage drift amount. Stage drift is determined to exist when the current transaction status is "completed" and the original push intent is a promotional intent for the same product, a price reduction reminder intent for the same product, or an order promotion intent; stage drift is determined to exist when the current transaction status is "after-sales" and the original push intent is a product promotion intent or a repeat purchase reminder intent; stage drift is determined to exist when the current transaction status is "rejected" and the original push intent is a product promotion intent, a price reduction reminder intent, a discount reminder intent, an order promotion intent, or a repeat purchase reminder intent. For the same product, the determination is based on the consistency of the product identifier.

[0057] The negative feedback drift is determined based on the number of push notification closing events, the number of ignored events, and the number of unsubscribe events. An ignored event refers to a push notification that has been recorded by the e-commerce platform server as delivered to the target user's terminal, but the target user did not generate an open event, click event, close event, or unsubscribe event within the valid deadline of the push notification. Only one ignored event is counted for the same push notification. If the target user generates an unsubscribe event, the e-commerce platform server uses this unsubscribe event as a strong trigger condition for active rejection drift.

[0058] The e-commerce platform server generates both active rejection drift results and passive scenario drift results, and determines the final intent drift value of the candidate push information based on these two results. When the active rejection drift result meets the failure condition, the candidate push information is directly transferred to the failed push queue; when the passive scenario drift result meets the freezing condition but not the failure condition, the candidate push information is transferred to the frozen push queue and awaits re-verification; when neither the active rejection drift result nor the passive scenario drift result meets the freezing condition, the candidate push information is marked as push information to be verified and enters the push relationship graph for processing.

[0059] The e-commerce platform server stores active rejection failure conditions, passive scenario freezing conditions, freezing thresholds, and failure thresholds. Active rejection failure conditions determine whether the active rejection drift caused by push notification closing, ignoring, and unsubscribing events has reached the point of stopping transmission. Passive scenario freezing conditions determine whether the passive scenario drift caused by order placement, order cancellation, and refund events has reached the point of temporarily suspending transmission. Freezing and failure thresholds are used to classify the final intent drift value, with the failure threshold being greater than the freezing threshold.

[0060] The freeze threshold and failure threshold are generated offline by the e-commerce platform server based on historical push logs. Specifically, the e-commerce platform server calculates the corresponding historical intent drift value for each historical candidate push message in the historical push log and labels it according to the processing results after the historical candidate push message is sent. When a historical candidate push message is sent and no push-close event, ignore result, or unsubscribe event is generated, it is labeled as a normal sample; when a historical candidate push message has a change in transaction status before and after sending, and an ignore result or push-close event is generated after sending, it is labeled as a frozen sample; when a historical candidate push message has a completed, after-sales, or refused-reach status before and after sending, and is still sent and a push-close event, unsubscribe event, or order status conflict result is generated, it is labeled as a failed sample. The e-commerce platform server generates the freeze threshold and failure threshold based on the distribution of historical intent drift values ​​corresponding to normal samples, frozen samples, and failed samples.

[0061] When the intent drift value is less than the freeze threshold, the e-commerce platform server marks the candidate push information as push information to be verified. Push information to be verified is then processed in the push relationship graph.

[0062] When the intent drift value is greater than or equal to the freeze threshold but less than the failure threshold, the e-commerce platform server marks the candidate push information as frozen push information and transfers it to the frozen push queue. Frozen push information is not sent immediately. The e-commerce platform server records the reason for freezing and the re-verification time. Reasons for freezing include category drift, stage drift, and negative feedback drift.

[0063] The re-verification time is determined based on the reason for the freeze and stored in the freeze record corresponding to the freeze push message. When the reason for the freeze is category drift, the re-verification time is the moment the target user generates a behavior event related to the same product category, or the moment after the first verification interval configured by the platform from the freeze time, whichever comes first. When the reason for the freeze is stage drift, the re-verification time is the moment the order status changes again, or the moment after the second verification interval configured by the platform from the freeze time, whichever comes first. When the reason for the freeze is negative feedback drift, the re-verification time is the moment the target user enters a new session window, or the moment after the third verification interval configured by the platform from the freeze time, whichever comes first. The first, second, and third verification intervals are configured by the e-commerce platform according to the platform push task processing cycle and stored in the freeze verification configuration table.

[0064] When the re-verification time is reached, the e-commerce platform server re-reads the task corresponding to the frozen push information to generate a snapshot, and re-executes the comparison between the status version number at the time of generation and the current status version number, as well as the calculation of the intent drift value. If the recalculated intent drift value is less than the freezing threshold, the frozen push information is converted into push information pending verification; if the recalculated intent drift value is greater than or equal to the failure threshold, the frozen push information is transferred to the failure push queue; if the recalculated intent drift value is still greater than or equal to the freezing threshold but less than the failure threshold, the frozen push information remains in the frozen push queue, and the re-verification time is reset according to the reason for freezing.

[0065] When the intent drift value is greater than or equal to the failure threshold, the e-commerce platform server marks the candidate push information as failed push information and transfers it to the failed push queue. Failed push information will no longer be included in the target push information determination process.

[0066] For candidate push notifications marked as pending verification, the e-commerce platform server establishes a push relationship graph. Nodes in the push relationship graph represent the push notifications to be verified, and the edges in the graph include conflicting edges and mutually exclusive edges.

[0067] A state conflict edge is a self-loop edge connecting the push notification node to itself, indicating a conflict between the original push intent and the current transaction status. A state conflict edge is generated on the push notification node when the current transaction status is "completed," the product identifier of the push notification matches the product identifier in a completed order, and the original push intent is a product promotion, price reduction reminder, or order promotion. A state conflict edge is also generated on the push notification node when the current transaction status is "after-sales," the product category code of the push notification matches the product category code in an after-sales order, and the original push intent is a product promotion or repeat purchase reminder. Finally, a state conflict edge is generated on the push notification node when the current transaction status is "rejected," and the product category code of the push notification matches the product category code of a closed or unsubscribed push notification.

[0068] Mutual exclusion edges are established between two different push information nodes to be verified. When two push information nodes to be verified correspond to the same product identifier, the same preferential benefit identifier, the same push channel identifier, or the same sending time window, a mutual exclusion edge is generated between the two push information nodes to be verified.

[0069] The same product identifier indicates that the two push notifications to be verified correspond to the same specific product. The same discount / benefits identifier indicates that the two push notifications to be verified correspond to the same coupon, the same discount / benefits, or the same promotional benefits. The same push channel identifier indicates that the two push notifications to be verified are intended to be sent through the same message channel. The same sending time window indicates that the planned sending times of the two push notifications to be verified are within the same sending time period configured on the platform.

[0070] Before determining the target push information, the e-commerce platform server first deletes push information nodes with state conflict edges. For multiple push information nodes with mutually exclusive edges, the e-commerce platform server retains the push information node with the latest generation time and no state conflict edges, and suppresses the other push information nodes with mutually exclusive edges with that node. The suppressed push information is transferred to the frozen push queue or the invalid push queue according to its intent drift value and valid deadline.

[0071] By using push relationship graph processing, e-commerce platform servers can eliminate push information that conflicts with the current transaction status before candidate push information is actually sent, and reduce duplicate push information for the same product, the same rights, the same channel, or the same sending time window.

[0072] After processing the push relationship graph, the e-commerce platform server determines the sending method of the target push information based on the current push channel load. The current push channel load includes the current push queue length, the number of pushes received by the same target user within a preset time, and the number of pushes sent within the current time window using the same push channel.

[0073] ; in, The current push channel load, This is the current push queue length. This refers to the maximum queue length configured for the corresponding push channel on the e-commerce platform server. This refers to the number of push notifications received by the same target user within a preset time period. This sets the maximum number of push notifications a single target user is allowed to receive within a preset time period. This refers to the number of messages sent within the current time window using the same push channel. This represents the maximum number of messages that can be sent within the current time window using the same push channel. , , Assign channel load weights, and satisfy: ; in, , and The e-commerce platform configures the push channel capacity, platform message sending rules, and user push frequency limits, and stores the configuration in the channel load configuration table. , , The e-commerce platform server configures the load weight based on the congestion of different push channels and user frequency limits, and stores it in the channel load weight table.

[0074] when When the value is less than or equal to 1, the e-commerce platform server allows the target push information to be sent immediately. When the value is greater than 1, the e-commerce platform server will delay or merge the sending of the target push information. For target push information with an effective deadline approaching and no state conflict edges, the e-commerce platform server will prioritize its sending. For multiple target push information messages with the same product identifier, the same preferential benefit identifier, or the same push channel identifier, the e-commerce platform server will merge them into a single target push information message before sending it.

[0075] After the target push message is sent, the e-commerce platform server records the task identifier, sending time, sending channel, terminal delivery status, open status, click status, closed status, ignored status, and unsubscribe status of the target push message. These records are entered into the historical push log and used for subsequent updates to the drift weight table, freeze threshold, failure threshold, negative feedback frequency baseline value, and channel load configuration table.

[0076] A target user browses a mobile phone product on an e-commerce platform. Upon entering the platform, the e-commerce platform server establishes a current session window and records the session identifier. The target user sequentially generates search events, product detail browsing events, and similar product comparison events. The e-commerce platform server converts these behavioral event data into event feature records and forms an event feature record sequence according to the event occurrence time. The state recognition model outputs the current transaction state as a price comparison state based on the event feature record sequence.

[0077] The e-commerce platform server generates a candidate push notification based on the product details browsing event. The original intent of this candidate push notification is to remind users of a price reduction. Simultaneously, the e-commerce platform server generates a task snapshot, recording the product category code, product identifier, transaction status at the time of generation, status version number at the time of generation, and expiration time corresponding to the candidate push notification.

[0078] Before the candidate push notification is actually sent, the target user completes the order and payment. After detecting the order event, the e-commerce platform server updates the current transaction status to "completed" and increments the current status version number by one.

[0079] When the candidate push notification enters the pre-send verification process, the e-commerce platform server reads the snapshot generated by the task and finds that the status version number at the time of generation is inconsistent with the current status version number, and the current time is not later than the valid deadline. The e-commerce platform server matches the current transaction status with the original push intent. Since the current transaction status is "completed" and the original push intent is a price reduction reminder for the same product, the corresponding stage drift S in the status intent conflict table is set to 1. The e-commerce platform server calculates the intent drift value based on the category drift, stage drift, and negative feedback drift. If the intent drift value is greater than or equal to the failure threshold, the candidate push notification is marked as a failed push notification and transferred to the failed push queue, and will no longer be sent to the target user terminal.

[0080] If a candidate push notification for after-sales service exists simultaneously, and its original push intent is also after-sales service, and the product identifier in its task-generated snapshot matches the product identifier in the completed order, the e-commerce platform server performs pre-send verification on this candidate push notification, marks it as a push notification to be verified, and adds it to the push relationship graph. Since this push notification to be verified does not have a state conflict with the current transaction state, the e-commerce platform server does not generate a state conflict edge on this node. If there are no mutually exclusive edges between this node and other push notifications to be verified, and the current push channel load L is less than or equal to 1, then the e-commerce platform server determines this candidate push notification for after-sales service as the target push notification and sends it to the target user terminal.

[0081] Therefore, this application does not continue to recommend similar products after the target user has purchased the product. Instead, it determines whether the candidate push information has expired based on the status version number and intent drift value before sending the candidate push information, and controls the actual sending of the candidate push information by freezing the push queue, the expired push queue, the push relationship graph, and the current push channel load.

[0082] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An e-commerce information push method based on artificial intelligence, characterized in that, Includes the following steps: S1: Obtain behavioral event data generated by the target user in the current session window, convert the behavioral event data into event feature records, and input the event feature records arranged according to the occurrence time into the status recognition model to obtain the current transaction status of the target user; S2: When generating candidate push information, a snapshot is generated for the task of generating the candidate push information. The task snapshot includes the original push intent, triggering event, product category code, product identifier, transaction status at the time of generation, status version number at the time of generation, and valid deadline. S3: When a key behavioral event is detected in the target user, the current transaction status is updated according to the key behavioral event, and the current status version number corresponding to the current transaction status is updated. The key behavioral events include order placement event, order cancellation event, refund event, push notification closure event, and push notification unsubscription event. S4: Before sending the candidate push information, read the task generation snapshot corresponding to the candidate push information, compare the status version number at the time of generation with the current status version number, and compare the current time with the valid deadline; S5: When the current time is later than the effective deadline, the candidate push information is marked as invalid push information and transferred to the invalid push queue; S6: When the generated state version number is inconsistent with the current state version number, and the current time is not later than the effective deadline, generate the intent drift value corresponding to the candidate push information based on the current transaction status, the original push intent, the product category code, the state change time, the transaction behavior time sequence characteristics, and the push rejection behavior time sequence characteristics. The intent drift value includes active rejection drift results and passive scenario drift results. The active rejection drift results are determined based on push notification closing events, ignore events, and unsubscribe events. The passive scenario drift results are determined based on order placement events, order cancellation events, refund events, and status change times. S7: Based on the intent drift value, mark the candidate push information as push information to be verified, frozen push information, or invalid push information, wherein the frozen push information is transferred to the frozen push queue and waits for re-verification, and the invalid push information is transferred to the invalid push queue and stops sending. S8: Establish a push relationship graph for the push information to be verified. The nodes in the push relationship graph are the push information to be verified. The edges in the push relationship graph include state conflict edges and mutual exclusion edges. The state conflict edges are determined based on the conflict relationship between the original push intention of the push information to be verified and the current transaction status. The mutual exclusion edges are determined based on the product duplication relationship, equity duplication relationship, push channel duplication relationship and time window conflict relationship between the two push information to be verified. S9: Based on the push relationship graph and the current push channel load, determine the target push information from the push information to be verified that has never had a state conflict edge, and send the target push information to the target user's terminal.

2. The e-commerce information push method based on artificial intelligence according to claim 1, characterized in that, The event feature record includes event type code, product category code, product identifier, price range code, event occurrence time, session identifier, and push channel identifier; The current session window is bounded by the session identifier, starting at the moment the session is established when the target user enters the e-commerce platform, and ending at the moment the target user exits the e-commerce platform, the moment the target user completes order payment, the moment the target user generates an unsubscribe push event, or the moment when no new behavioral event data is generated for 30 consecutive minutes.

3. The method for pushing e-commerce information based on artificial intelligence according to claim 2, characterized in that, The state recognition model takes event feature records arranged according to the occurrence time as input and takes browsing state, price comparison state, pending transaction state, completed transaction state, after-sales state, or refused contact state as output. When the most recent key behavioral event in the behavioral event data is an order placement event, and there are no order cancellation events or refund events after the order placement event, the current transaction status is determined to be a completed status; When the most recent key behavioral event in the behavioral event data is a refund event, the current transaction status is determined to be an after-sales status; when there is an unsubscribe push event in the behavioral event data, the current transaction status is determined to be a refused-reach status.

4. The e-commerce information push method based on artificial intelligence according to claim 3, characterized in that, The current status version number is recorded independently under each session identifier of the target user; When an order placement event, order cancellation event, refund event, push notification shutdown event, or push notification unsubscription event is detected, the e-commerce platform server increments the current status version number by one. When a search event, product details browsing event, similar product comparison event, or add-to-cart event is detected, the current state version number remains unchanged.

5. The method for e-commerce information push based on artificial intelligence according to claim 4, characterized in that, The original push intents include product promotion intent, price reduction reminder intent, discount reminder intent, order promotion intent, after-sales service intent, and repeat purchase reminder intent; The triggering event is the behavioral event data on which the candidate push information is generated; The effective deadline is determined based on the original push intention and the triggering event, and is stored in correspondence with the task identifier of the candidate push information.

6. The e-commerce information push method based on artificial intelligence according to claim 5, characterized in that, When generating the intent drift value, the e-commerce platform server determines the category drift amount, stage drift amount, and negative feedback drift amount respectively; The category drift amount is determined based on the category difference between the product category code corresponding to the current transaction status and the product category code in the task-generated snapshot; The stage drift amount is determined based on the correspondence between the current transaction status and the original push intent in the status intent conflict table; The negative feedback drift amount is determined based on the number of times the target user closes, ignores, and unsubscribes from push notifications for the same product category in the current session window and within the 24 hours prior to the start of the current session window.

7. The method for pushing e-commerce information based on artificial intelligence according to claim 6, characterized in that, The product category code corresponding to the current transaction status is determined based on the most recent behavioral event data that triggered the current transaction status; When the current transaction status is browsing, comparing prices, or pending transaction, take the product category code from the most recent product details browsing event, similar product comparison event, or added to cart event; When the current transaction status is "completed", take the product category code of the product corresponding to the most recent order event; When the current transaction status is after-sales, take the product category code of the order corresponding to the most recent refund event; When the current transaction status is "rejected", take the product category code from the push information corresponding to the most recent close push event or unsubscribe push event.

8. The e-commerce information push method based on artificial intelligence according to claim 7, characterized in that, The state intent conflict table includes the correspondence between the current transaction state, the original push intent, and the stage drift amount; When the current transaction status is "completed" and the original push intention is the same product promotion intention, the same product price reduction reminder intention, or the same order promotion intention, the candidate push information is determined to have stage drift. When the current transaction status is after-sales status, and the original push intention is product promotion intention or repurchase reminder intention, the candidate push information is determined to have stage drift; When the current transaction status is a denied access status, and the original push intent is a product promotion intent, price reduction reminder intent, discount reminder intent, order promotion intent, or repeat purchase reminder intent, the candidate push information is determined to have stage drift. The same product can be identified by the consistency of its product label.

9. The e-commerce information push method based on artificial intelligence according to claim 8, characterized in that, The e-commerce platform server stores a freeze threshold and an invalidation threshold, and the invalidation threshold is greater than the freeze threshold; When the intent drift value is less than the freeze threshold, the candidate push information is marked as push information to be verified. When the intent drift value is greater than or equal to the freeze threshold and less than the failure threshold, the candidate push information is marked as frozen push information; When the intent drift value is greater than or equal to the failure threshold, the candidate push information is marked as failed push information; The freezing threshold and the failure threshold are determined based on historical push logs, which include the generation time of candidate push information, sending time, target user transaction status change time, push closing event, push unsubscription event, and order status change result.

10. The e-commerce information push method based on artificial intelligence according to claim 9, characterized in that, When the freeze push information is transferred to the freeze push queue, the e-commerce platform server records the reason for the freeze and the re-verification time. When the re-verification time is reached, the e-commerce platform server rereads the task generation snapshot corresponding to the frozen push information, and re-executes the comparison between the state version number at the time of generation and the current state version number, as well as the generation of the intent drift value. If the regenerated intent drift value is less than the freezing threshold, the frozen push information is converted into push information to be verified. If the regenerated intent drift value is greater than or equal to the failure threshold, the frozen push information is transferred to the failure push queue. If the regenerated intent drift value is greater than or equal to the freeze threshold and less than the failure threshold, the frozen push information is kept in the frozen push queue and the re-verification time is re-determined. When generating the intent drift value, the e-commerce platform server determines the dynamic drift weight based on the transaction behavior timing characteristics and the push rejection behavior timing characteristics; The transaction behavior timing characteristics include the chronological relationship between the order placement event, order cancellation event, refund event and the generation time of candidate push information; the push rejection behavior timing characteristics include the chronological relationship between the push closing event, ignore event, unsubscribe event and the generation time of candidate push information. The e-commerce platform server adjusts the proportions of category drift, stage drift, and negative feedback drift in the intent drift value according to the dynamic drift weights. The e-commerce platform server determines the state timing decay coefficient based on the time interval between the state change time and the candidate push information sending verification time. As the time interval increases, the impact of stage drift caused by passive scene drift is reduced; When a target user generates a push notification close event or unsubscribe event within the time interval, the negative feedback drift effect generated by the active rejection drift is maintained.

Images