Private letter social interaction method and system based on network marketing platform

Abstract

The invention relates to the technical field of network communication, in particular to a private message social interaction method and system based on a network marketing platform, and the method comprises the steps: firstly responding to batch sending action triggering of a private message sending request, and verifying the authorization state of a private message sending end; if the authorization state verification is passed, performing double check on the sending quota of the private message sending end, and pre-occupying the sending quota after the check is passed; verifying the private message type of the private message sending request by adopting a preset message verifier; then, calling a preset message builder to generate a message body corresponding to the private message type; and finally, according to the pre-occupied sending quota, calling a platform API to send a message body, and monitoring a return state in real time. During the period, when a current limiting error code is captured, an exponential backoff retry strategy is executed to execute message reissuing. According to the method provided by the invention, double check can be automatically performed on the sending quota, so that the rate / frequency limitation of the corresponding platform is met, and the condition that the user account is marked as abnormal or forbidden is avoided.

Description

Technical Field

[0001] This invention relates to the field of network communication technology. More specifically, this invention relates to a method and system for private messaging social interaction based on an online marketing platform. Background Technology

[0002] With the rapid development of the e-commerce industry, especially the rise of short videos and live-streaming e-commerce, communication between merchants and influencers has become crucial. To achieve viable collaborations, merchants typically send out invitations or marketing messages to a large number of influencers. Currently, there are two main methods for reaching out: bulk email sending and bulk forwarding of personal messages. These two methods have the following drawbacks: While bulk email sending is relatively inexpensive, it relies on industry consensus, with an open rate of only 15%-25% and a response rate of only 5%-10%, resulting in poor reach and feedback. Furthermore, it lacks real-time two-way interactive capabilities, making it difficult to meet the demands of fast-paced e-commerce marketing.

[0003] Regarding the aforementioned email delivery issues, manually sending private messages to contact influencers or using simple scripts is clearly more efficient. However, in a multi-threaded concurrent environment, the APIs of mainstream marketing platforms have strict rate / frequency limits, such as a limit of only 60 requests per minute. The scripts mentioned above are prone to triggering rate-limiting errors, leading to accounts being flagged as abnormal or banned. Furthermore, after a single failed private message attempt, conventional scripts will retry indiscriminately, further exacerbating account abnormalities.

[0004] Therefore, existing private messaging technologies mainly suffer from unreliability issues. Summary of the Invention

[0005] To address the unreliability of the existing technology, this invention discloses a private messaging social interaction method and system based on an online marketing platform.

[0006] In a first aspect, this invention discloses a private messaging social interaction method based on an online marketing platform, comprising: In response to a batch sending action triggered by a private message sending request, verify the authorization status of the private message sender; If the authorization status verification passes, the sending quota of the private message sender is double-checked, and the sending quota is reserved after the check passes. The private message type of the private message sending request is verified using a preset message verifier; Invoke the preset message builder to generate the message body corresponding to the private message type; Based on the pre-allocated sending quota, the platform API is invoked to send the message body, and the return status is monitored in real time. During this process, when a rate-limiting error code is captured, an exponential backoff retry strategy is executed to resend the message.

[0007] Preferably, the sending quota of the private message sender is double-checked, including: Read the sent count from the distributed cache; Determine if the sent count is greater than or equal to the sent quota; If so, reject the private message sending request; If not, use the Redis distributed lock component to obtain the user's operation lock; While holding the operation lock, read the sent count from the distributed cache again; Determine if the sent count is greater than or equal to the sent quota; If so, the quota is deemed insufficient and the private message sending request is rejected; If not, perform quota deduction and release the operation lock.

[0008] The preferred index backoff retry strategy is as follows: Determine if the error code returned by the API is a specific rate-limiting flag; If so, suspend the current thread; The suspension duration increases incrementally according to a preset exponential sequence; after the suspension duration is exceeded, the message body is resent.

[0009] The preferred formula for calculating the suspension duration is:

[0010] In the formula, Indicates the first Suspension duration for each retry Indicates the initial waiting time. Indicates the current number of retries.

[0011] Preferably, if the current number of retries reaches the maximum number of retries, the reserved sending quota will be returned to the distributed cache.

[0012] Preferably, after successfully sending the message body via the platform API, the method of the present invention further includes: It adopts a dual-track mechanism that combines passive reception based on an event-driven architecture with timed active retrieval to synchronize message sending status and session records.

[0013] Preferably, the passive receiving mechanism based on the event-driven architecture is as follows: Receive Webhook requests pushed by the platform; the Webhook request includes a request header and a request body; Extract the signature information from the request header; Perform a hash operation on the request body to obtain the result; The calculation result is compared with the signature information for consistency. If the consistency check passes, the unique message identifier in the request body is parsed, and the received message is idempotent based on the distributed set to discard duplicate messages.

[0014] The preferred mechanism for periodically and actively fetching data is as follows: Periodically scan the local database to obtain the last synchronization timestamp of each active session; Call the platform session history API, passing the last synchronization timestamp as the cursor parameter; Retrieve the list of incremental messages after the last synchronization timestamp and update the session records in the local database.

[0015] Preferred private message types include graphic cards, product cards, text, images, targeted invitation cards, and emojis.

[0016] Secondly, the present invention discloses a private message social interaction system based on an online marketing platform, including a processor and a memory. The memory stores computer program instructions, and when the computer program instructions are executed by the processor, the private message social interaction method based on an online marketing platform described in the first aspect is implemented.

[0017] The beneficial effects of this invention are as follows: (1) Compared with the prior art, in a multi-threaded concurrent environment, the method of the present invention can automatically perform double checks on the sending quota to meet the rate / frequency limit of the corresponding platform and avoid the situation where the user account is marked as abnormal or banned. Therefore, the method of the present invention has higher reliability.

[0018] (2) Compared with the prior art, the method of the present invention has stronger two-way interaction capabilities, which promotes efficient and reliable connection between merchants and experts.

[0019] (3) Compared with the prior art, the method of the present invention supports the push of multiple message types to adapt to different marketing scenarios. Attached Figure Description

[0020] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the invention are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein: Figure 1 This is a flowchart of the private message social interaction method based on an online marketing platform in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the structure of the private message social interaction system based on the online marketing platform in Embodiment 2 of the present invention. Detailed Implementation

[0021] 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, not all, of the embodiments of the present invention. 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.

[0022] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0023] Example 1 like Figure 1 As shown, this embodiment discloses a private message social interaction method based on an online marketing platform, including: S10: In response to the batch sending action triggered by the private message sending request, verify the authorization status of the private message sender.

[0024] It should be explained that after configuring the push recipients and private message push types, users click "One-Click Push," triggering step S10 above. At this time, the user's authorization status on the platform (e.g., TikTok) includes a user level tag, such as guest, regular member, premium member, or super member. Different user levels have different push permissions and daily message push quotas. Therefore, in addition to verifying the user level, scope verification is also required to determine the message push permissions and daily quotas granted to the user's authorization status.

[0025] Before step S10, the method of this embodiment further includes: S100: Monitor the remaining validity period of the authorized access token.

[0026] S101: When the remaining validity period is less than the preset threshold, use a distributed lock to lock the refresh operation, call the platform refresh interface to obtain a new access token and refresh token, and update it to the database.

[0027] The steps S100-S101 described above can automatically refresh the user's login status and the validity period of the Token (digital identity communication proof), thereby reducing the possibility of the user automatically logging off due to prolonged inactivity and ensuring the long-term stability of the method in this embodiment.

[0028] S20: If the authorization status verification passes, double-check the sending quota of the private message sender, and reserve the sending quota after the check passes.

[0029] Specifically, after the authorization status verification is successful, the user's level and associated permissions can be determined. The steps for double-checking the sending quota of the private message sender are as follows: S21: Read the sent count from the distributed cache.

[0030] In this embodiment, the distributed cache mentioned above refers to Redis, a database that stores data directly in memory, supports multiple data types and distributed locks, and is suitable for caching and high-concurrency application scenarios. The time range for the sent count is "daily," but in other embodiments, "hourly" can also be used as the time range for the sent count. Pre-allocated sending quota refers to allocating a quota to each push object.

[0031] S22: Determine whether the sent count is greater than or equal to the sent quota.

[0032] S23: If so, reject the private message sending request.

[0033] It should be explained that the above steps S21-S23 are lock-free fast judgments, which aim to quickly reject users who do not meet the quota conditions without consuming Redis lock resources. This step can block 99% of users who do not meet the conditions and improve the overall performance of the method in this embodiment.

[0034] S24: If not, use the Redis distributed lock component to obtain the user's operation lock.

[0035] Specifically, when the first round of judgment passes, a distributed operation lock is granted to the user. When the user is granted the operation lock, it is equivalent to giving priority to a certain execution thread in its concurrent push thread. At this time, the execution of other threads can only be carried out when the lock is released.

[0036] S25: While holding the operation lock, read the sent count from the distributed cache again.

[0037] S26: Determine whether the sent count is greater than or equal to the sent quota.

[0038] S27: If so, determine that the quota is insufficient and reject the private message sending request.

[0039] S28: If not, perform quota deduction and release the operation lock.

[0040] It should be further explained that, apart from the locking and unlocking operations, steps S24-S27 are not significantly different from steps S21-S23. The reason for setting up two layers of repetitive checks is that the functions of the secondary checks are different, specifically in the following ways: The initial check intercepts subsequent requests when the quota is exhausted or significantly insufficient, preventing resource waste and thread blocking caused by a large number of invalid requests competing for the distributed lock. This ensures that the system maintains high efficiency even under high concurrency.

[0041] The second check effectively avoids the risk of "overselling" caused by changes in data state during multi-threaded concurrent waiting for lock release, ensuring strict adherence to the platform's daily quota limits and thus preventing account bans.

[0042] To illustrate more vividly, imagine a lock as a window, and quota operations as allocating train tickets. The first check is similar to having everyone (in this example, referring to processes) check on the electronic board or app to see if there are any "remaining tickets." If not, they will not try to occupy the window.

[0043] Compared to existing technologies, the method of this invention possesses a superior distributed quota control strategy, enabling precise control of sending quotas through the aforementioned Redis atomic operations and double-checked queries. While maximizing quota utilization, it reduces over-allocation caused by concurrent preemption, effectively lowering the likelihood of user accounts being flagged as abnormal or banned.

[0044] S30: Use a preset message verifier to verify the private message type of the private message sending request.

[0045] In this embodiment, the aforementioned private message types include graphic cards, product cards, text, images, targeted invitation cards, and emojis. The push file formats for these private message types differ and require verification by a message verifier. The message verifier is a message type route; during the verification process, type mappings need to be defined.

[0046] For example, for an API on a major platform, the type mapping table is as follows:

[0047] It should be noted that the systems associated with the above internal types are mainly CRM systems. However, the APIs vary depending on the platform, so the corresponding mapping relationships also differ and need to be configured in advance.

[0048] During the verification process in step S30, the message verifier uses the mapping relationship to verify the private message type of the private message sending request, as a credential for generating the corresponding type template.

[0049] S40: Call the preset message builder to generate the message body corresponding to the private message type.

[0050] It's important to explain that a message builder is a script that encapsulates various types of templates. For different private message types, the message builder integrates the message sending request content into the corresponding template to generate the appropriate message body. Specifically, message bodies for image / text cards, product cards, or targeted invitation cards will include interactive buttons that redirect to a specific page.

[0051] S50: Based on the pre-allocated sending quota, call the platform API to send the message body and monitor the return status in real time; during this process, when a rate-limiting error code is captured, execute the exponential backoff retry strategy to resend the message.

[0052] Specifically, the platform API automatically generates template-based message bodies and pushes them to the corresponding recipients, monitoring the return status in real time. This status includes whether the message has been received, read, saved, deleted, or if the recipient has provided feedback. Rate limiting error codes are exception codes returned by the platform system. Different platforms have different rate limiting error codes, so it's necessary to predefine specific error code representations in the program's recognition script.

[0053] Furthermore, the aforementioned index retreat and retry strategy is specifically as follows: S51: Determine whether the error code returned by the API is a specific rate-limiting identifier.

[0054] S52: If so, suspend the current thread.

[0055] The suspension duration increments according to a preset exponential sequence. After the suspension duration is exceeded, the message body is resent.

[0056] Furthermore, the formula for calculating the suspension duration is as follows:

[0057] In the formula, Indicates the first Suspension duration for each retry Indicates the initial waiting time. Indicates the current number of retries.

[0058] Through the above technical solution, the method in this embodiment does not require manual retry logic. By adopting an exponential backoff approach, it can avoid the avalanche effect, thereby giving the server recovery time. Furthermore, the aforementioned exponential backoff retry strategy can increase the success rate of private message retry pushes from 60% to 95% within four retries.

[0059] It should be noted that the above retries are only performed for a single specific rate limiting flag and not for other errors. In addition, the retry process holds a distributed lock during the retry process to avoid duplicate transmission of information.

[0060] Furthermore, if the current number of retries reaches the maximum number of retries, the reserved sending quota will be returned to the distributed cache. When the retries reach the limit, the reserved sending quota will be returned and the corresponding distributed lock will be released to reclaim resources.

[0061] Furthermore, after successfully sending the message body via the platform API, the method in this embodiment also includes: S60: It adopts a dual-track mechanism that combines passive reception based on event-driven architecture with timed active retrieval to synchronize message sending status and session records.

[0062] Through the above step S60, the method of this embodiment has bidirectional real-time interaction capability. More specifically, it can rely on two dual-track feedback mechanisms, namely Webhook and active pull mechanism, to achieve millisecond-level message synchronization.

[0063] Furthermore, the mechanism for passively receiving data based on an event-driven architecture in step S60 above is specifically as follows: S611: Receives Webhook requests pushed by the platform.

[0064] A Webhook request consists of a request header and a request body. The request header contains metadata such as a signature, content type, or timestamp. The request body contains the actual business information.

[0065] S612: Extract signature information from the request header.

[0066] It should be noted that when the user being pushed the information sends it back through the platform, the platform encapsulates it into a signature using the "key + request body" method and places it in the request header.

[0067] S613: Perform a hash operation on the request body to obtain the result.

[0068] Specifically, upon receiving a message, the HMAC-SHA256 hash algorithm is used to calculate the signature of the request body.

[0069] S614: Perform a consistency comparison between the calculation result and the signature information.

[0070] S615: If the consistency comparison passes, parse the unique message identifier in the request body, and perform idempotency verification on the received message based on the distributed set to discard duplicate messages.

[0071] Through the above steps S611-S615, the method of this embodiment can prevent the forgery of information return by verifying the signature, and can also prevent the repeated transmission of the same information.

[0072] Furthermore, in step S60 above, the mechanism for periodically and actively pulling data is specifically as follows: S621: Periodically scan the local database to obtain the last synchronization timestamp of each active session.

[0073] S622: Call the platform session history API, passing the last synchronization timestamp as the cursor parameter.

[0074] S623: Retrieve the list of incremental messages after the last synchronization timestamp and update the session records in the local database.

[0075] Through the above steps S621-S623, in addition to passively receiving messages, the method of this embodiment also supports periodically actively pulling information. Compared with the traditional one-way passive reception, this two-way real-time feedback can still achieve message acquisition as a backup even if Webhook push is lost, through active pulling.

[0076] It should be further explained that step S20 above is a preventative rate limiting measure, while the exponential backoff retry strategy in step S50 is a passive rate limiting measure. Based on both, monitoring feedback can be used to adjust the global push rate. Specifically, the rate limiting error rate can be monitored; when the error rate exceeds the error rate threshold, the global push rate is reduced, and the push batch size and push latency are dynamically adjusted.

[0077] By employing the three-layer rate limiting control method described above—namely, preventative measures, passive retry, and global control—this embodiment can reduce the likelihood of user accounts being marked as abnormal or banned while ensuring efficient information delivery.

[0078] In summary, compared with the prior art, the method of this embodiment has at least the following technical advantages: Firstly, it has a dual-track feedback mechanism of Webhook and active retrieval, which can achieve millisecond-level message synchronization.

[0079] Secondly, it has a three-tiered rate limiting strategy, which can ensure a high message delivery rate and account security.

[0080] Third, it can support the automatic generation of various message types to adapt to different marketing scenarios.

[0081] Fourth, it has complete session lifecycle management and can realize multi-terminal information synchronization.

[0082] Fifth, it has an OAuth security mechanism, which maintains the stability of the method execution process in this embodiment through automatic token refresh and distributed lock concurrency.

[0083] Sixth, precise quotas are achieved through Redis operations and a double-check mechanism.

[0084] Example 2 like Figure 2 As shown, this embodiment also discloses a private message social interaction system based on an online marketing platform, including a processor and a memory. In this embodiment, the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the private message social interaction method based on an online marketing platform described in the first aspect is implemented.

[0085] The system in this embodiment also includes other components well known to those skilled in the art, such as communication interfaces. Their settings and functions are known in the art, and therefore will not be described in detail here.

[0086] In this invention, the aforementioned memory can be any tangible medium containing or storing a program that can be used or combined with an instruction execution system, apparatus, or device. For example, a computer-readable storage medium can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc., or any other medium that can be used to store desired information and can be accessed by an application, module, or both. Any such computer storage medium can be part of a device or accessible to or connected to a device. Any application or module described in this invention can be implemented using computer-readable / executable instructions that can be stored or otherwise maintained by such a computer-readable medium.

[0087] In the description of this specification, "multiple" means at least two, such as two, three or more, etc., unless otherwise expressly and specifically defined.

[0088] While this specification has shown and described numerous embodiments of the invention, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will occur to those skilled in the art without departing from the spirit and essence of the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in the practice of this invention.

Claims

1. A method for private messaging social interaction based on an online marketing platform, characterized in that, include: In response to a batch sending action triggered by a private message sending request, verify the authorization status of the private message sender; If the authorization status verification passes, the sending quota of the private message sender is double-checked, and the sending quota is reserved after the check passes. The private message type of the private message sending request is verified using a preset message verifier; Invoke the preset message builder to generate the message body corresponding to the private message type; Based on the pre-allocated sending quota, the platform API is invoked to send the message body, and the return status is monitored in real time. During this process, when a rate-limiting error code is captured, an exponential backoff retry strategy is executed to resend the message.

2. The private message social interaction method based on an online marketing platform according to claim 1, characterized in that, The sending quota of the private message sender is double-checked, including: Read the sent count from the distributed cache; Determine whether the sent count is greater than or equal to the sent quota; If so, reject the private message sending request; If not, use the Redis distributed lock component to obtain the user's operation lock; While holding the operation lock, read the sent count from the distributed cache again; Determine whether the sent count is greater than or equal to the sent quota; If so, the quota is deemed insufficient and the private message sending request is rejected; If not, perform quota deduction and release the operation lock.

3. The private message social interaction method based on an online marketing platform according to claim 1, characterized in that, The index backoff and retry strategy is as follows: Determine if the error code returned by the API is a specific rate-limiting flag; If so, suspend the current thread; The suspension duration increases according to a preset exponential sequence; after the suspension duration is exceeded, the message body is resent.

4. The private message social interaction method based on an online marketing platform according to claim 3, characterized in that, The formula for calculating the suspension duration is: In the formula, Indicates the first Suspension duration for each retry Indicates the initial waiting time. Indicates the current number of retries.

5. The private message social interaction method based on an online marketing platform according to claim 4, characterized in that, If the current number of retries reaches the maximum number of retries, the reserved sending quota will be returned to the distributed cache.

6. The private message social interaction method based on an online marketing platform according to claim 1, characterized in that, After successfully sending the message body via the platform API, the method further includes: It adopts a dual-track mechanism that combines passive reception based on an event-driven architecture with timed active retrieval to synchronize message sending status and session records.

7. The private message social interaction method based on an online marketing platform according to claim 6, characterized in that, The mechanism for passively receiving data based on an event-driven architecture is as follows: Receive a Webhook request pushed by the platform; wherein the Webhook request includes a request header and a request body; Extract the signature information from the request header; Perform a hash operation on the request body to obtain the result; The calculation result is compared with the signature information for consistency. If the consistency comparison passes, the unique message identifier in the request body is parsed, and the received message is idempotent based on the distributed set to discard duplicate messages.

8. The private message social interaction method based on a network marketing platform according to claim 6, characterized in that, The mechanism for periodically and proactively fetching data is as follows: Periodically scan the local database to obtain the last synchronization timestamp of each active session; Call the platform session history API, passing the last synchronization timestamp as the cursor parameter; Retrieve the list of incremental messages after the last synchronization timestamp and update the session records in the local database.

9. The private message social interaction method based on an online marketing platform according to claim 1, characterized in that, The types of private messages include graphic cards, product cards, text, images, targeted invitation cards, and emojis.

10. A private messaging social interaction system based on an online marketing platform, characterized in that, It includes a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the private message social interaction method based on any one of claims 1-9 is implemented.

Images