Universal partner fission marketing method, system and electronic device across business partners

Abstract

This invention discloses a universal partner-based viral marketing method, system, and electronic device across multiple business parties. The method maintains globally unique partner identity data across multiple business parties, ensuring that partner identities are not bound to any single business party. It receives the activation configuration and revenue-sharing rule configuration of pre-set viral roles on the platform from the business parties. Using the business party as the isolation dimension, it stores the team viral relationships between partners in a data structure that includes the business party identifier dimension, ensuring that the team viral relationships of the same partner under different business parties are independent and do not interfere with each other. In response to a consumption event, it calculates chain-like revenue sharing based on the revenue-sharing rules configured by the corresponding business party and generates a revenue-sharing record. This invention achieves cross-business party sharing of promoter identities while isolating the viral relationships and rules of each business party. It also ensures relationship consistency and revenue-sharing correctness through unique key constraints, audit state machines, idempotent keys, and other technical features.

Description

Technical Field

[0001] This invention relates to the field of internet marketing and data processing technology, specifically to a viral marketing method, system, and electronic device that enables cross-business sharing of partner identities and isolation of team fission relationships among multiple independent business entities. Background Technology

[0002] Existing affiliate marketing and distribution systems typically establish an independent partner system and fission relationship tree for a single business entity, with partner identities strongly bound to that business entity. For example, one known solution discloses a four-level distribution chain of "platform—channel partner—brand owner—user," where the entire chain is fixed within a single business system, lacking cross-business entity sharing capabilities, and its claims are purely business process descriptions, lacking technical features such as data structures, isolation mechanisms, and state machines.

[0003] Another known scheme discloses a fission-style sharing of member information, where consumer members can share across merchants and participate in revenue sharing, but their fission relationship is tied to a single merchant, and what is shared is the consumer identity rather than the promoter identity.

[0004] The closest prior art to this invention is a membership sharing management system and method for merchants (publication number CN111311287B, hereinafter referred to as the prior art). In this prior art, the integration module uploads the anonymized and categorized membership data of each merchant to the sharing platform; after merchants apply and negotiate to reach a "sharing agreement," the push module uses an "identity recognition unit" to determine whether the membership identities of the two sharing merchants are the same. If they are the same, a clearing signal is generated, the push is stopped, and a new member is selected to supplement the data. Its technical purpose is "cross-merchant traffic redirection and promotion of consumer membership data," and the method for handling the situation of "the same member appearing in multiple merchants" is "duplicate removal."

[0005] The aforementioned prior art shares the following common technical defects: First, the shared objects are misaligned. The existing "member sharing" shares end-consumer / member data for cross-merchant traffic redirection and promotion; rather than the identity of promoters / partners, which is used to reuse the promoter's promotional capabilities across business units. Second, the identity processing direction is reversed. In the case of "the same entity appearing in multiple business parties / merchants", the comparison file is processed as "deduplication and removal", that is, it is regarded as redundant and eliminated; while in the cross-business party promotion scenario, the same promoter legally and in parallel works for multiple business parties, and its identity should be "isolated and coexisting", that is, each is independent and does not contaminate each other under different business parties, rather than being eliminated; Third, there is a lack of a multi-level fission relationship tree isolated by business unit. Existing solutions do not have a "multi-level team fission relationship tree stored in isolation by business unit". When a partner promotes for multiple business units at the same time, if there is no isolation, the hierarchical fission relationships under each business unit will inevitably contaminate each other and conflict with the rules.

[0006] Therefore, a technical solution is needed to enable a single partner system to serve multiple independent business parties, while maintaining the isolation and independent configuration of the fission relationships and rules of each business party, and supporting the correct and concurrent secure calculation of chain-based profit sharing. Summary of the Invention

[0007] I. Technical Problem to be Solved by the Invention This invention aims to solve the problem of how to maintain the isolation and independent configuration of the fission relationship and profit-sharing rules of each business team while sharing partner identities across business units, and to ensure the consistency of relationships and the correctness of profit-sharing.

[0008] To address the aforementioned technical problems, this invention provides a universal partner-based viral marketing method across business entities, comprising: The system maintains partner identity data, with each partner identity having a globally unique identifier across multiple business parties and not bound to any single business party; it receives the activation configuration and profit-sharing rule configuration of the platform's pre-set fission roles from business parties; it stores the team fission relationship between partners in a data structure containing the business party identifier dimension, with the business party as the isolation dimension, so that the team fission relationship is bound to the first business party, and the team fission relationships of the same partner under different business parties are independent of each other and do not contaminate each other; in response to consumption events, it calculates chained extraction of profit-sharing according to the profit-sharing rules configured by the corresponding business party and generates profit-sharing records. Furthermore, at the data structure level, the team fission relationship data structure at least includes a business party identifier, a subordinate partner identifier, a superior partner identifier, an approval status, and a relationship status. Through a unique key constraint using the business party identifier as the dimension, it is ensured that the same partner has only one valid superior relationship within the same business party. The team fission relationships are stored in the same data structure with the business party identifier field as the isolation dimension, and team fission relationships under different business parties are isolated from each other by this business party identifier field. When querying across business parties, the business party identifier is used as a filtering condition, ensuring that the query results only include relationship data within the current business party dimension. Furthermore, at the configurability level, the fission role is a platform-preset role that can be enabled or disabled by each business unit. When a business unit does not enable the fission role, no team fission relationship is established under that business unit, and no chain-like commission is generated. The activation configuration of the fission role is a switch-on configuration; after activation, the business unit obtains fission marketing capabilities without additional code development. Furthermore, regarding the accuracy of profit sharing, the profit sharing record is equipped with an idempotent key, which is determined by a combination of the business party identifier, the consumption event identifier, and the consumption event source type. Before generating a profit sharing record, the system checks whether a calculated profit sharing record already exists based on the combination; if it does, it is not calculated again. The profit sharing record transitions between three states: pending calculation, calculated, and settled, with the settled state being the final state. The calculation basis for the chain-style profit sharing is the profit sharing performance amount of the lower-level partners (rather than the number of lower-level partners), thus avoiding the compliance risks of headcount-based compensation from the calculation basis. Furthermore, at the compliance control level, the chain-based revenue sharing parameters include a chain depth parameter; the platform-level maximum chain depth limit is a fixed platform-level value that cannot be changed by the business party; when calculating the chain-based revenue sharing, calculation stops for levels exceeding the maximum chain depth limit. When establishing the team fission relationship, loop detection is performed on the chain path of the relationship; if a loop is detected, the establishment is rejected. Furthermore, at the relationship lifecycle management level, the request to establish a team relationship must be reviewed by a superior. The review status transitions between a set of states including pending review, approved, rejected, timed out, and revoked. When the pending review status exceeds a preset threshold duration, it automatically transitions to the timed-out status and is handled according to a preset fallback strategy. When a partner leaves or is removed from the business unit, the team relationship of their direct subordinates is atomically migrated to their superior within a database transaction, and an anti-washing chain mark is set for the direct subordinates. The migration and setting are committed within the same transaction to ensure consistency, while retaining historical profit-sharing records. The anti-washing chain mark is stored in the team fission relationship data structure, preventing unbound subordinate partners from being rebound to new superior partners within the same business unit.

[0009] This invention also provides a corresponding cross-business-side universal partner-based viral marketing system, including a partner identity module, a business-side configuration module, a team relationship module, a profit-sharing calculation module, and a compliance control module. These modules work together to implement the aforementioned methods. This invention also provides a corresponding electronic device and computer-readable storage medium.

[0010] Compared with the prior art, the present invention has the following beneficial effects: Partner identities are shared across business units, avoiding the duplication of building partner systems for each business unit, and promoter resources and reputation can be reused across business units; Team relationships are isolated by business unit, and each business unit's fission rules, commission rates, and chain depth are configured independently and do not pollute each other; The platform has pre-defined roles that can be configured with the business side's on / off settings, allowing new business sides to gain the ability to expand rapidly without developing additional code. Compared to the "duplicate removal" processing method of the aforementioned comparison files, the present invention adopts the "isolation and coexistence" processing for the identity of the same partner in multiple business parties. The two technologies are opposite. The former regards the appearance of the same entity in multiple merchants as redundant and eliminates it, while the latter regards the parallel participation of the same partner in multiple business parties as a legitimate scenario and stores it independently, thereby correctly supporting the real business needs of promoters to serve multiple business parties in parallel. The platform-level hard cap for chain depth, combined with ring detection, and the chain-based profit sharing based on the profit sharing performance amount (rather than the number of people) avoids the compliance risks of multi-level compensation and headcount compensation from a technical architecture perspective. The audit state machine, lower-level migration, and anti-washing chain constraints ensure the continuity and consistency of the fission relationship tree under personnel changes; Idempotent and unique key constraints ensure the correctness of profit sharing calculation and concurrency relationship establishment.

[0011] To further illustrate the inventiveness of this invention, a problem-solution approach is adopted for analysis as follows: The closest prior art is the aforementioned comparative document (publication number CN111311287B), which shares consumer membership data and uses "duplicate removal" to handle duplicate occurrences of the same member across multiple merchants, and does not include a team fission relationship tree. The distinguishing technical feature of this invention compared to the comparative document is that it stores team fission relationships in a data structure containing the business party identifier dimension, using the business party identifier as the isolation dimension, so that the hierarchical fission relationships of the same partner under different business parties are independent and do not contaminate each other. The technical problem actually solved by the distinguishing technical feature is: how to avoid mutual contamination and rule conflicts in hierarchical fission relationships under different business parties when partner identities are shared across business parties, and to ensure relationship consistency and profit sharing correctness. For the above technical problem, the technical suggestion given by the comparative document is "eliminating duplication," which is the opposite of the "isolation and coexistence" approach of this invention; and the comparative document does not disclose or suggest a multi-level team fission relationship data structure stored according to business party isolation. Therefore, those skilled in the art cannot derive the technical solution of the present invention from the combination of the aforementioned prior art with existing distribution and affiliate marketing schemes. The present invention has prominent substantive features and significant progress. Attached Figure Description

[0012] Figure 1 This is the main flowchart of the method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the hierarchical architecture of partner identity and team relationship in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the isolated storage of team relationships by business party in an embodiment of the present invention; Figure 4 This is a flowchart of the chain-based profit-sharing calculation according to an embodiment of the present invention; Figure 5This is a schematic diagram of the audit state machine transition according to an embodiment of the present invention; Figure 6 This is a schematic diagram comparing the embodiments of the present invention with the prior art document "Duplicate Removal vs. Isolation and Coexistence". Detailed Implementation

[0013] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. The following embodiments are used to illustrate the present invention, but do not limit the scope of protection of the present invention.

[0014] For ease of understanding, the following explanations are provided for some of the terminology used in this invention: (1) Business party: Independent business line accessing the platform, each business party has a business party identifier AppId; (2) Partner: Promoters registered on the platform. Each partner has a globally unique identifier, PartnerId, that spans multiple business parties. (3) Consumption events: Events reported back by the business party that reflect the consumption or service use of end users, which serve as the trigger for chain-like profit sharing; (4) Team fission relationship: the hierarchical promotion relationship between partners, expressed by the binding of lower-level partners with higher-level partners; (5) Platform Virtual Partner: A virtual identifier preset by the platform, used as a backup for the lower level when the upper level's review expires or is rejected; (6) Chain washing: refers to the behavior of partners repeatedly unbinding and re-attaching to a superior for arbitrage; anti-chain washing constraint refers to the constraint that prohibits unbound partners from rebinding to a new superior under the same business party.

[0015] This embodiment maintains four types of core data in the computer system: (1) Partner Identity Data: Each partner has a globally unique identifier, PartnerId, across multiple business parties, and records registration time, initial reputation value, etc. Partner identity is not bound to any single business party; (2) Business party configuration data: Each business party has a business party identifier AppId and records the fission role activation flag, commission parameters, chain depth parameters, annual decay parameters and other profit sharing rule configurations; (3) Team fission relationship data: Each record includes the business party identifier AppId, subordinate partner identifier, superior partner identifier, review status, relationship status, application time, effective time, chain depth, chain path, and anti-fraud chain marker. The data structure is stored with AppId as the isolation dimension; (4) Profit sharing record data: Each record includes the business party identifier AppId, consumption event identifier, superior / subordinate identifier, role identifier, profit sharing amount, profit sharing base, profit sharing rate, chain depth, settlement status, and idempotent key.

[0016] like Figure 2 As shown, the system is divided into three layers from top to bottom: the business party layer, the partner identity layer, and the team relationship layer. The partner identity layer is shared globally, while the team relationship layer is stored in the same data structure with the business party identifier field as the isolation dimension. Relationship records under different business parties are isolated from each other.

[0017] like Figure 1 and Figure 3 As shown, this embodiment includes the following steps: Step S1: The system maintains the globally unique identifier PartnerId of partner P1. P1 is not bound to any business party. Step S2: Business APP1 activates the platform's pre-set fission role (configured chain commission rate: 15% for level 1, 10% for level 2; chain depth 2); Business APP2 also activates it (configured chain commission rate 10%, chain depth 2). Step S3: P1 submits a request to bind its superior P2 under APP1; P2 approves the request; the system writes a record R1={AppId=APP1, subordinate=P1, superior=P2, approval status=approved, chain depth=1, chain path=OFFICIAL>P2>P1} into the team fission relationship data structure.

[0018] P1 submits a request to bind to its parent P3 under APP2; P3 approves the request; the system writes the record R2={AppId=APP2, Subordinate=P1, Parent=P3, Approval Status=Approved, Chain Depth=1, Chain Path=OFFICIAL>P3>P1}.

[0019] Because R1 and R2 have different business entity identifiers, they coexist in isolation: P1's parent P2 under APP1 does not constrain the fission relationship of P1 under APP2, nor does it pollute each other.

[0020] Furthermore, a unique key constraint (AppId, lower-level partner identifier) ​​is set in the data structure with the business party identifier as the dimension to ensure that P1 can only have one valid superior under APP1 (it cannot be attached to P2'); if an attempt is made to attach repeatedly, the unique key constraint will refuse to write.

[0021] Furthermore, team fission relationships are stored in the same data structure with the business party identifier field as the isolation dimension, and the relationship records of APP1 and APP2 are isolated from each other by the app_pin field; when performing cross-business party queries (such as counting the relationships of P1 in all business parties), the business party identifier is used as the filtering condition, so that the query results are returned separately according to the business party dimension, and cross-business party pollution does not occur.

[0022] The difference between this embodiment and the aforementioned comparative document is that in the comparative document, when the identity recognition unit determines that the same member is in the same merchant account on both platforms, a clearing signal is generated and the push is stopped, and a new member is selected (i.e., "duplicate clearing"); while in this embodiment, the relationship between the same partner P1 in APP1 and APP2 is legally isolated and coexist (i.e., "isolated coexistence"). The two have opposite technical directions. Figure 6 As shown.

[0023] like Figure 4 As shown, this embodiment includes the following steps: Step S4: The system receives a consumption event E={AppId=APP1, source identifier=E, business type=T, confirmed revenue=1000}.

[0024] The system analyzes the parent chain of partner P4, which generated the consumption under APP1: P4→P1→P2, with a chain depth of 2, which does not exceed the platform's maximum chain depth limit.

[0025] The system calculates commission levels according to the chain-like commission rules configured in APP1: P1 receives 150 yuan (15%), P2 receives 100 yuan (10%). The commission is based on the performance amount of the lower-level partners, not the number of people.

[0026] The system queries whether a profit-sharing record for the event already exists based on the combination of (APP1, E, source type). If it does not exist, it writes the profit-sharing record and sets the settlement status to "calculated". When the same event E is received repeatedly, the system matches an existing record based on the combination and does not recalculate; the status eventually transitions to the "settled" final state.

[0027] Furthermore, the maximum chain depth of the platform is fixed at 2 (a platform-level compliance constant that cannot be changed by the business side); if the depth of the upper-level chain exceeds 2 during the calculation, the profit sharing calculation will stop for the level exceeding the limit.

[0028] Furthermore, when establishing team relationships, the system performs loop detection on the chain path; if a loop is detected (for example, P attempts to attach itself to its own subordinate), the system refuses to establish the team fission relationship.

[0029] like Figure 5 As shown, requests to establish team relationships require approval from a superior, and the approval status transitions between the following sets of statuses: PENDING → APPROVED: Approved by superiors; Pending review → Rejected: If rejected by the superior, the subordinate will be reassigned to the platform's virtual partner OFFICIAL. Pending review → Timeout: If the pending review exceeds the preset threshold time (e.g., 3 days), it will automatically move to timeout and be handled according to the fallback strategy, which will affix the subordinate to the superior of the superior, or affix it to the platform virtual partner OFFICIAL. Pending review → Withdrawal (WITHDRAWN): The applicant withdraws the application voluntarily; after withdrawal, the applicant can reapply and change the superior authority, but the old withdrawal record will be retained for auditing.

[0030] The review status transition does not allow cross-state jumps (e.g., once approved, it cannot be rolled back to pending review).

[0031] When partner P2 exits or is removed from business APP1, the system atomically completes the downstream migration and anti-washout chain setting within a database transaction, as follows: Start a transaction; update the team relationship of P2's direct subordinates (including P1) under APP1 to the superior of P2 (i.e., P1's superior is updated from P2 to P2's superior); set the anti-spam chain mark in the relationship record of the direct subordinates; P1's historical profit sharing record remains unchanged, only the ownership of subsequent new transactions changes; the above two updates, team relationship migration and anti-spam chain mark setting, are committed in the same transaction, and the two either take effect at the same time or are rolled back at the same time. This ensures the consistency of the fission relationship tree under APP1 before and after migration, avoiding inconsistent intermediate states such as "the lower level has been migrated but the anti-washing chain mark is not set (it can be immediately reattached to the new upper level for arbitrage)" or "the anti-washing chain mark is set but the lower level has not been migrated (the relationship is suspended)". The anti-chain-washing flag is stored in the team fission relationship data structure after being set. When P1 subsequently initiates a request to rebind its superior under APP1, the system rejects it based on this flag, preventing P1 from establishing a new superior relationship under APP1. This prevents "chain-washing" (i.e., the behavior of repeatedly unbinding and re-attaching for arbitrage).

[0032] This embodiment provides a universal partner-based viral marketing system that spans multiple business units, including a partner identity module, a business unit configuration module, a team relationship module, a profit-sharing calculation module, and a compliance control module. These modules work together to implement the methods described above.

[0033] This embodiment also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0034] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0035] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A universal partner-based viral marketing method across business units, characterized in that, Includes the following steps: S1. Maintain partner identity data in a computer system, wherein each partner identity has a globally unique identifier across multiple business parties, and the partner identity is not bound to any single business party. S2. Receive the first business party's configuration for enabling the fission role preset on the platform and the corresponding profit-sharing rules, wherein the profit-sharing rules include at least chain-based commission-related parameters; S3. In response to the request to establish a team relationship under the first business party, with the business party as the isolation dimension, in the team fission relationship data structure containing the business party identifier dimension, store the team fission relationship between the first partner as the superior and the second partner as the subordinate, which is bound to the first business party. The data structure has a unique key constraint composed of the business party identifier and the subordinate partner identifier, so that the same partner can only have one valid team fission relationship record under the same business party; and the team fission relationship of the first partner under other business parties is independent of the team fission relationship under the first business party. The superior or subordinate relationship of the first partner under the first business party does not constrain or pollute the fission relationship of the first partner under other business parties. S4. In response to a consumption event associated with the second partner under the first business entity, according to the profit-sharing rules configured by the first business entity, the upper-level chain of the second partner is parsed level by level along the team fission relationship under the first business entity, and the upper-level chain is truncated according to the maximum chain depth limit at the platform level. For each upper-level chain that is not truncated, the chain-like extraction of profit-sharing is calculated according to its profit-sharing rules, and a profit-sharing record containing idempotent keys is generated.

2. The method according to claim 1, characterized in that, The team fission relationship data structure includes at least the business party identifier, the subordinate partner identifier, the superior partner identifier, the review status, and the relationship status; the unique key constraint is a unique index composed of the business party identifier and the subordinate partner identifier.

3. The method according to claim 2, characterized in that, The team fission relationships are stored in the same data structure with the business party identifier field as the isolation dimension. The team fission relationships under different business parties are isolated from each other by the business party identifier field. When querying across business parties, the business party identifier is used as a filtering condition so that the query results only contain the relationship data of the current business party dimension.

4. The method according to claim 1, characterized in that, The fission role is a pre-set role on the platform that can be enabled or disabled by each business party; when a business party does not enable the fission role, the team fission relationship will not be established under that business party and the chain-like commission will not be generated.

5. The method according to claim 4, characterized in that, The activation configuration of the fission role is a switch-on configuration; after the business party activates the fission role preset by the platform, it can obtain fission marketing capabilities without additional code development.

6. The method according to claim 1, characterized in that, The profit-sharing record has an idempotent key, which is determined by a combination of the business party identifier, the consumption event identifier, and the consumption event source type. Before generating the profit-sharing record, the system queries whether a calculated profit-sharing record already exists based on the combination. If it does, the record is not calculated again. The profit-sharing record transitions between three states: pending calculation, calculated, and settled. The settled state is the final state.

7. The method according to claim 1, characterized in that, The calculation basis for the chain-style profit sharing is the profit sharing performance amount of the lower-level partners.

8. The method according to claim 1, characterized in that, The maximum chain depth limit at the platform level is a fixed value at the platform level that cannot be changed by the business party; during the process of calculating the chain-based profit sharing and parsing level by level along the upper chain, the calculation of chain-based profit sharing is stopped for levels that exceed the maximum chain depth limit.

9. The method according to claim 8, characterized in that, When establishing the team fission relationship, a loop detection is performed on the chain path of the relationship; if a loop is detected, the establishment of the team fission relationship is rejected.

10. The method according to claim 1, characterized in that, The request to establish a team relationship must be reviewed by a superior. The review status will transition between a set of statuses including pending review, approved, rejected, timed out, and withdrawn. When the pending review status exceeds a preset threshold time, it will automatically transition to the timed out status and be handled according to a preset fallback strategy. The fallback strategy includes affixing the second partner to the superior of the first partner or affixing it to a virtual partner on the platform.

11. The method according to claim 1, characterized in that, When the first partner leaves or is removed from the first business entity, the following updates are atomically executed in a database transaction: the team relationships of the first partner's direct subordinates under the first business entity are migrated to the first partner's superiors, the anti-washing chain flag is set on the relationship records of the direct subordinates, and the historical profit-sharing records generated by the first partner before leaving are retained; the team relationship migration and the setting of the anti-washing chain flag are committed in the same transaction, so that the two either take effect at the same time or roll back at the same time, to ensure the consistency of the fission relationship tree under the first business entity before and after the migration, and to avoid inconsistent intermediate states such as migrated but rebinding, or set but not migrated.

12. The method according to claim 11, characterized in that, The anti-washing chain marker is stored in the team fission relationship data structure; any subsequent requests from the direct subordinate partner to rebind to the superior initiated by the first business party are rejected based on the anti-washing chain marker in the team fission relationship data structure, so that the unbound subordinate partner cannot be rebound to a new superior partner under the first business party.

13. A universal partner-based viral marketing system across business units, characterized in that, include: The Partner Identity module is used to maintain globally unique partner identity data across business units; The business configuration module is used to receive the activation configuration and profit-sharing rule configuration of the platform's pre-set fission roles from the business side. The team relationship module is used to store the team fission relationship between partners with the business party as the isolation dimension, and to ensure that the same partner has only one valid superior relationship under the same business party by using the unique key constraint of the business party identifier dimension in the team fission relationship data structure. The profit sharing calculation module is used to calculate the chained extraction of profit sharing based on the profit sharing rules configured by the business party and generate profit sharing records containing idempotent keys. The compliance control module is used to truncate the chain depth of the upper-level chain that performs chain extraction, based on the platform's maximum chain depth limit, and to perform ring detection. The modules work together to implement the method described in claim 1.

14. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method as described in claim 1.

15. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method as described in claim 1.

Images