A cross-platform advertisement delivery anti-cheating and strategy optimization method

Abstract

The application discloses a cross-platform advertisement putting anti-cheating and strategy optimization method, relates to the technical field of advertisement putting data processing and putting management optimization, and receives putting event data and business side corresponding verification event data returned by multiple advertisement platforms, arranges the putting event data and the verification event data according to unified time, unified event and unified identification, forms an evidence package around a business result, performs cross-platform association, identifies attribution contention events and verification insufficient events, forms an isolated account book and a correction account book, and performs budget migration, bid adjustment and recovery verification according to the correction account book and the isolated observation relationship. The method can complete unified processing, source association, credibility correction and pollution isolation of cross-platform heterogeneous event data, avoid cheating pollution data from continuously entering a budget allocation and bid adjustment link, and improve budget migration accuracy, putting strategy stability and overall putting income level.

Description

Technical Field

[0001] This invention relates to the field of advertising data processing and advertising management optimization technology, specifically a cross-platform advertising anti-fraud and strategy optimization method. Background Technology

[0002] In advertising campaigns, advertisers typically connect to multiple media platforms, traffic platforms, or channel platforms simultaneously. Based on data from each platform, such as impressions, clicks, activations, registrations, orders, and payments, they continuously optimize budget allocation, bid adjustments, campaign pacing, creative selection, and channel retention / retention. Existing cross-platform campaign systems usually aggregate performance data from different platforms and calculate metrics like click-through rate, conversion rate, customer acquisition cost, conversion rate, and ROI according to preset standards. Based on this, they then perform budget migration, bid adjustments, and channel ranking. Meanwhile, existing anti-fraud solutions primarily target abnormal clicks, bulk activations, fake registrations, fake devices, bot access, click injection, and attribution hijacking within a single platform. They filter, downgrade, or block suspicious traffic based on device identification, network address, click frequency, event interval, behavioral path, or blacklist rules.

[0003] However, in real-world cross-platform campaigns, different platforms exhibit inconsistencies in log structures, device identification systems, event definition methods, attribution windows, timezone definitions, deduplication rules, postback latency, and anti-fraud criteria. The identifiers of the same user on different platforms are difficult to directly correlate, and the recording time, attribution source, and validity judgment results of the same conversion event may also differ across platforms. Some platforms only return aggregated results, lacking detailed event data for in-depth comparison. Consequently, while existing technologies can identify some invalid traffic within a single platform, the identification results typically remain within that platform, making it difficult to uniformly process heterogeneous event data across platforms. Furthermore, it is challenging to unify and correct inconsistent, contradictory, or fraudulently-contaminated performance feedback across different platforms.

[0004] Furthermore, most existing cross-platform optimization systems assume that data returned from each platform can be directly used as the basis for budget optimization. Even if some clicks, activations, registrations, or payment signals have been contaminated by fraudulent traffic, the system may still continue to perform budget migration and bid adjustments based on these seemingly good-performing data. This leads to a continuous tilt of the budget towards traffic sources with low or even fraudulent real growth, resulting in problems such as distorted budget migration, squeezed-out high-quality channels, abnormal fluctuations in campaign timing, increased attribution bias, and a decline in overall campaign revenue.

[0005] Therefore, current technologies still lack a unified solution for processing heterogeneous event data returned from different platforms in cross-platform advertising scenarios. This solution would enable the unified processing of such data, including source correlation, credibility correction, and pollution isolation of fraudulent signals at the cross-platform level, before feeding the corrected results back into budget allocation, bid adjustment, and campaign strategy optimization. Preventing performance data contaminated by fraudulent traffic from continuously entering the cross-platform optimization process, and preventing the erroneous migration of budgets to traffic sources with seemingly high conversion rates but low actual incremental growth or even fraudulent activity, has become a pressing technical problem in cross-platform advertising management. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a cross-platform advertising anti-fraud and strategy optimization method, which solves the problems of difficulty in uniformly processing heterogeneous event data, difficulty in completing cross-platform source correlation and credibility correction of fraud pollution signals, and continuous entry of polluted performance data into the budget migration and bid adjustment links, resulting in budget migration distortion and reduced advertising revenue.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a cross-platform advertising anti-fraud and strategy optimization method, comprising: S1. Receive campaign event data from multiple advertising platforms and receive corresponding verification event data from the business side. S2. Organize the data on the delivery event and the verification event according to the unified time standard, unified event standard and unified identification standard, and form an evidence package based on the business results; S3. Based on the evidence package, perform cross-platform association, identify attribution contention events and insufficient verification events, and transfer the corresponding events to the segregated ledger to form a segregated observation relationship; S4. Based on the evidence package, cross-platform correlation results, and segregated ledger, attribution corrections are made for events that have not been transferred to the segregated ledger and written into the correction ledger; S5. Perform budget migration and bid adjustment based on the corrected ledger and the isolation observation relationship, and perform recovery verification after the strategy is executed.

[0008] Furthermore, S1 includes: Establish a platform access list and a business event definition sheet for the same deployment task; The platform access list should include the platform name, account number, plan number, unit number, creative number, landing page version number, delivery region, device type, platform original time zone, data feedback frequency, platform event naming rules, platform click tag field, platform device tag field, platform attribution tag field, attribution observation window, platform allowable late time, platform delivery status field, and platform data version field. The business event caliber form should include the business target type, business unified time zone, verification event name, result confirmation caliber, verification completion boundary, unique business result number field, access entry mark source, session mark source, user mark source, and business side log source. The platform access list and business event caliber list remain fixed within the same deployment task cycle. When adjustments are made, they are re-registered with the new version number, and only the newly added records after the adjustment take effect.

[0009] Furthermore, S1 also includes: Write the event data to the original event pool and write the verification event data to the verification event pool. The event data in the original event pool should retain at least the following fields: platform source, platform event number, platform original event name, platform original occurrence time, platform original time zone, account number, campaign number, unit number, creative number, landing page version number, platform click tag, platform device tag, platform attribution tag, network address, delivery region, device type, platform feedback status, and platform data version. The verification event data in the verification event pool should retain at least the following fields and values: business event number, business event name, business occurrence time, business unified time zone, access entry tag, session tag, user tag, order number, payment number, lead number, business page tag, business status, result confirmation status, unique number of business result, and single version field of business event scope; When at least one of the following fields and values ​​in the verification event data is missing: business event number, business event name, business occurrence time, result confirmation status, and unique number of business result, the data is transferred to the field pending verification pool. When event data is delayed beyond the specified limits, it is transferred to the delayed event pool. When a record arrives duplicated, the duplicate marking process is executed.

[0010] Furthermore, S2 includes: Using the unified business time zone as the sole time benchmark, we will perform unified time standardization on both event delivery data and verification event data. The platform's original event names and business's original event names are standardized using a pre-established event mapping sheet. The unified identification criteria are organized using the unique business result number field and value, order number, lead number, user tag, access entry tag, session tag, platform click tag, platform device tag, and auxiliary tags formed by combining network address, delivery region and unified event time. After completing the aforementioned organization, a standard event log is generated.

[0011] Furthermore, S2 also includes: Perform retrospective analysis on standard event records according to candidate association key levels to form an evidence package around the confirmed core business results; Each evidence package should retain at least the evidence package number, central business result number, central business result type, evidence chain start time, evidence chain end time, associated platform set, chain integrity status, and current verification status; When the same user generates multiple business results within the same observation window, the evidence package is split first based on the unique number field and value of the business result. If the unique number field of the business result is missing, the evidence package is split based on the time of occurrence of the business result and the session tag. Payment candidate events will only proceed to the subsequent processing procedure if a payment completion record exists in the evidence package. If a payment completion record is missing but a payment receipt or payment number exists that can correspond to the business results of the corresponding center, the payment receipt or payment number will be used as supplementary verification evidence.

[0012] Furthermore, S3 includes: Establish cross-platform association groups using evidence packages as the basic processing unit; Perform a unified check on the consistency of event time, candidate association key level, access entry record, session continuity, landing page version number, and business page tag across all platform links within the same evidence package; When the business results of the same center are simultaneously associated with two or more platforms under the same time caliber and it is impossible to exclude any of the platforms, it is recorded as an attribution contention event. The situation where the verification record corresponding to the central business result is missing and exceeds the verification completion boundary is recorded as a verification insufficiency event. The verification record is determined according to the business objective type.

[0013] Furthermore, S3 also includes: Event states are formed based on attribution contention events and undervalidated events; The event status is fixed as normal, pending verification, isolated, and review. Events that are in a state of isolation are written into the isolation ledger; The records in the isolation ledger are aggregated by platform, plan, unit, creative, and landing page version to form isolation observation relationships; When the same unit repeatedly experiences an isolation state event within a preset number of consecutive observation windows, the unit is recorded as an isolation flow segment. When an isolated event continuously corresponds to the same creative and the same landing page version within a preset number of consecutive observation windows, the corresponding creative and the corresponding landing page version are recorded as the observation traffic segment.

[0014] Furthermore, S4 includes: The standard event records and evidence packages are filtered based on the segregated ledger to form a set of events to be corrected; The central business results in the set of events to be corrected have not been written to the isolated ledger, the corresponding evidence package is not in the state of incomplete link or pending supplementary evidence, the corresponding central business results have not been marked as revoked by the business side, and the corresponding event status is normal. Group the set of events to be corrected according to the central business results, and perform attribution correction according to the candidate association key level, access entry record consistency, session start consistency, landing page version number and business page tag consistency; When a unique attribution level cannot be determined, the attribution should be collected level by level in a fixed order: creative number, unit number, plan number, account number, and platform level.

[0015] Furthermore, S4 also includes: Based on the correction results, determine the correction attribution platform, correction attribution level, and evidence level, and record them in the correction ledger; The levels of evidence are fixed as high evidence level, medium evidence level, and basic evidence level; Evidence levels are determined in a fixed order of high evidence level, medium evidence level, and basic evidence level. Only one final evidence level is retained for the same business result within the same processing batch. Each record in the correction ledger must retain at least the correction number, standard event record number, evidence package number, central business result number, correction attribution platform, correction attribution level, unified event name, unified event time, evidence level, correction basis, and writing time. The allowed update time is the time interval from the time the corresponding correction record is written into the correction ledger to the time when the verification and completion boundary of the corresponding central business result expires. When a more complete verification record or a higher level of link evidence is received within the allowed update period, an upgrade update is performed on the corresponding correction record; When the results of central business operations are confirmed in subsequent batches to require transfer to the segregated ledger, the corresponding correction record is reversed.

[0016] Furthermore, S5 includes: Before the launch of the deployment task, the main granularity of strategy processing is determined in advance, and the strategy processing object is formed by combining the correction ledger and the isolation observation relationship according to the main granularity of strategy processing; The policy processing targets are fixedly divided into normal traffic segment, observed traffic segment, and isolated traffic segment; Based on the corrected ledger and the isolation observation relationship, the budget migration out and budget migration in targets are determined. Among them, the budget migration out targets are first determined from the isolation flow segment, and then determined from the observation flow segment when the isolation flow segment reaches the predetermined observation budget lower limit. The budget migration in targets are determined from the normal flow segment, and budget migration and bid adjustment are performed. Generate strategy version records after budget migration and bid adjustments; After the policy version record takes effect, recovery verification is performed based on the isolated ledger and correction ledger formed in subsequent continuous observation windows, combined with the isolated ledger and correction ledger of the corresponding batch before the policy version took effect. If the recovery verification result is unsuccessful, and there is a previous stable strategy version that has passed the recovery verification, the current strategy version will revert to the previous stable strategy version; if there is no previous stable strategy version in the current strategy version, the current strategy version will revert to the preset backup strategy version.

[0017] Compared with existing technologies, this invention provides a cross-platform advertising anti-fraud and strategy optimization method, which has the following beneficial effects: 1. This invention receives campaign event data from multiple advertising platforms and corresponding verification event data from the business side. It organizes the campaign and verification event data according to unified time, event, and identifier standards, forming an evidence package around the business results. Based on this evidence package, it performs cross-platform correlation to identify attribution contention events and insufficiently verified events, transferring the corresponding events to an isolated ledger. Events not transferred to the isolated ledger undergo attribution correction and are written to a correction ledger. Based on the correction ledger, it performs budget migration and bid adjustments. This enables unified processing, source correlation, credibility correction, and contamination isolation of heterogeneous event data returned from different platforms at the cross-platform level. It prevents performance data contaminated by fraudulent traffic from continuously entering the budget optimization process, solving the problems of distorted budget migration, biased identification of genuine high-quality traffic sources, and overall decreased campaign revenue in existing cross-platform advertising scenarios.

[0018] 2. This invention further establishes isolated observation relationships based on the formation of isolated ledgers, and determines normal traffic segments, observed traffic segments, and isolated traffic segments in conjunction with correction ledgers. Budget migration, bid adjustment, and recovery verification are performed on different strategy processing objects respectively. After the strategy version takes effect, recovery verification and strategy rollback are performed based on the isolated ledgers and correction ledgers formed in subsequent continuous observation windows. This can suppress the continuous amplification of abnormally high conversion signals, reduce the impact of erroneous budget tilt, abnormal rhythm fluctuations, and distorted attribution results on subsequent campaign management, and ensure that budget migration, bid adjustment, and strategy rollback are based on the corrected results, thereby improving the stability, reliability, and overall controllability of cross-platform advertising campaign strategy adjustments. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of a cross-platform advertising anti-fraud and strategy optimization method according to 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: Figure 1 A cross-platform advertising anti-fraud and strategy optimization method is presented, including: S1. Receive campaign event data from multiple advertising platforms and receive corresponding verification event data from the business side. The specific implementation is as follows: First, it receives campaign event data from multiple advertising platforms and corresponding verification event data from the business side. This data serves as the foundation for subsequent unified organization, evidence package formation, cross-platform association, isolation processing, attribution correction, ledger generation, and recovery verification.

[0022] In actual execution, first establish a platform access list and a business event definition sheet for the same campaign. The platform access list records the platform name, account number, campaign number, unit number, creative number, landing page version number, campaign region, device type definition, platform original time zone, data feedback frequency, platform event naming rules, platform click tag field, platform device tag field, platform attribution tag field, attribution observation window, platform allowable late time, platform campaign status field, and platform data version field.

[0023] The business event caliber form records the business target type, business unified time zone, verification event name, result confirmation caliber, verification completion boundary, unique business result number field, access entry mark source, session mark source, user mark source, and business side log source.

[0024] The unique number field for business results is used to uniquely identify the corresponding relationship of the same business result in each subsequent processing stage, and is pre-specified in the business event caliber sheet according to the business objective type.

[0025] When the business objective is payment, the field corresponding to the payment number should be prioritized as the unique identifier field for the business result; when the payment number is missing but the order number exists, the field corresponding to the order number should be prioritized as the unique identifier field for the business result.

[0026] When the business objective is to place an order, the field corresponding to the order number will be designated as the unique identifier field for the business result.

[0027] When the business objective is lead acquisition, the field corresponding to the lead number is designated as the unique number field for the business result; when the lead number is missing but the form system has generated a lead acceptance number, the field corresponding to the lead acceptance number is designated as the unique number field for the business result.

[0028] When the business system does not generate any independent number among the payment number, order number, and lead number, a temporary unique business result number value is formed by concatenating the business occurrence time, session tag, and business page tag in a fixed order of "business occurrence time + separator + session tag + separator + business page tag", and the corresponding field is recorded as the temporary unique business result number field.

[0029] Once a temporary business result unique number is generated, it remains unchanged until the corresponding business result completes the formal numbering. When a formal payment number, order number, or lead number is subsequently generated, the formal number is written into the business result unique number field and value, and a mapping relationship is established between the original temporary business result unique number value and the formal number, so that no new business result record is generated repeatedly.

[0030] Only one valid business result unique number field and value are allowed to be retained for the same business result; when the official number is replaced, the latest official number is used as the priority basis for subsequent standard event record organization, evidence package splitting, duplicate judgment and attribution correction, and the original temporary business result unique number value is only retained as the basis for traceability mapping.

[0031] The platform access list and business event caliber list remain fixed within the same deployment task cycle; if adjustments are necessary, they should be re-registered with the new version number, and only the newly added records after the adjustment are applied, without retrospectively changing existing records.

[0032] Based on the above, the system receives campaign event data from each advertising platform according to the platform access list. When campaign event data enters the raw event pool, the following fields are uniformly retained: platform source, platform event number, platform original event name, platform original occurrence time, platform original time zone, account number, campaign number, unit number, creative number, landing page version number, platform click tag, platform device tag, platform attribution tag, network address, campaign region, device type, platform feedback status, and platform data version. Among these, the network address is derived from the access network identifier field in the advertising platform's feedback log or the access network address field in the business-side access log. If the advertising platform does not provide a feedback network address, the access network address field in the business-side access log is used as a supplementary source.

[0033] The event types for campaign data are limited to one or more of the following: exposure events, click events, arrival events, activation events, registration events, order placement events, and payment events. If the campaign aims at registration and payment, it must accept at least one of the following events: click events, arrival events, registration events, order placement events, and payment events. If the campaign aims at activation, it must accept at least one of the following events: click events, arrival events, form submission events, phone number submission events, and lead confirmation events.

[0034] While receiving event data, we also receive verification event data from the business side. The verification event data uses the actual occurrence data from the business side, not the platform's self-reported data.

[0035] When verification event data enters the verification event pool, the following fields and values ​​are uniformly retained: business event number, business event name, business occurrence time, business unified time zone, access entry marker, session marker, user marker, order number, payment number, lead number, business page marker, business status, result confirmation status, unique business result number, and single-version field for business event caliber. Specifically, the business page marker originates from the page number field in the business system's page encoding table or the page number field in the page access log. If both the page encoding table and the page access log exist, the page number field in the page access log takes precedence. The access entry marker originates from the entry parameters, channel parameters, or the log of the first accessed page. If both entry parameters and channel parameters are missing, the arrival record corresponding to the log of the first accessed page is used as the source of the access entry marker. The session marker originates from the session number generated by the business system or business page during the first access. If no independent session number is generated for the current business scenario, the access session identifier that remains unchanged during the first consecutive access is used as the session marker. User tags are derived from login accounts, member IDs, registered accounts, or anonymous visitor IDs. If a login account, member ID, or registered account has not yet been generated before the current business result occurs, the anonymous visitor ID is used as the user tag. If the anonymous visitor ID is also missing, a session tag is used as a temporary user tag, and this will be added later when a formal user tag is generated. The result confirmation status indicates whether the current business result is confirmed, pending confirmation, or revoked. The result confirmation status is determined based on the result confirmation criteria in the business event caliber sheet, combined with the current business status, the revocation mark, and whether the corresponding verification record has arrived. If the corresponding verification record has arrived and meets the result confirmation criteria, it is recorded as confirmed. If the current result is still within the verification completion boundary and the corresponding verification record has not yet arrived completely, it is recorded as pending confirmation. If the business side has marked it as revoked, or if the result confirmation criteria determine that the current business result is no longer valid, it is recorded as revoked.

[0036] If the current business objective does not involve orders and payments, the order number and payment number fields are recorded as empty values, but the access entry marker, session marker, result confirmation status, and unique business result number fields and values ​​are still retained.

[0037] This step also establishes receiving rules. The platform's data transmission frequency is a fixed frequency of five minutes, fifteen minutes, thirty minutes, or one hour; the verification data update frequency is either one minute-level updates or real-time writing. The current processing batch is formed according to a preset observation window, and subsequent settlement batches are formed according to a preset settlement window.

[0038] In this embodiment, both the preset observation window and the preset settlement window are divided using fixed natural time windows. The preset observation window is used to form the current processing batch and serves as a unified time boundary for evidence packet splitting, isolation status event continuity statistics, observation traffic segment identification, isolation traffic segment identification, and window-by-window comparison for recovery verification. The preset settlement window is used to receive late collection records, include verification completion records, form historical addition boundaries, and perform settlement batch verification. The preset observation window can be divided into a fixed natural time window of one hour, four hours, or one day; the preset settlement window can be divided into a fixed natural time window of one day, three days, or seven days, and one preset settlement window must cover at least one complete preset observation window. Any event record is only included in one preset observation window according to its unified event time, and is also included in the corresponding preset settlement window according to its unified event time. Collection records are included in the corresponding preset observation window and preset settlement window statistics according to the original occurrence time. The arrival time is only used to determine whether the lateness exceeds the boundary and whether it enters the collection process, without changing the observation window and settlement window affiliation corresponding to the original time. The preset observation window and preset settlement window remain fixed within the same task deployment cycle; when adjustments are made, they are re-registered with the new version number and only apply to newly added processing batches after the adjustment.

[0039] If a platform does not send any new data back within two consecutive receiving cycles, the platform is first marked as being in a data return pending verification state. Then, the interface status, network transmission status, and authorization status are checked; this period is not directly considered a zero result. If, after checking, it is confirmed that the interruption duration does not exceed the preset settlement window, and the corresponding record can be collected after recovery, then the data is collected after recovery, and the original occurrence time is retained. If, after checking, it is confirmed that the field structure has changed, and at least one of the following is missing: platform event number, platform original event name, platform original occurrence time, account number, plan number, unit number, or creative number, then the corresponding record is transferred to the field pending verification pool and is not directly processed further. Verification event data is handled in the same way.

[0040] If the access log is normal but the order log is interrupted, only the verification events involving orders and payments will be transferred to the pending verification status. If the access log, session log, and result log are interrupted simultaneously, the current processing batch will be paused and formal processing will begin. Once the logs are restored, the corresponding business result link will be restored directly using the unique business result number field and value. If the unique business result number field and value are missing, a temporary supplementary link identifier will be formed by concatenating the session tag and access entry tag in a fixed order of "session tag + separator + access entry tag". If both the session tag and access entry tag are missing, supplementary link concatenation will not be performed, and the formal processing of the current processing batch will be paused.

[0041] When the platform does not send a response and an inspection confirms that the interface status, network transmission status, or authorization status is abnormal, but the interruption duration does not exceed the preset settlement window and the corresponding record can be collected after recovery, the corresponding platform's response status is recorded as a response pending verification status. After the anomaly is recovered and the collection is completed, the response pending verification status is lifted, and the collection record is written back to the original event pool according to the original occurrence time for continued processing. When the interruption duration exceeds the preset settlement window or the collection cannot be completed after recovery, the formal processing of the current batch is suspended.

[0042] This step also handles missing fields, late data, and duplicate data. First, a field integrity check is performed on the verification event data. If at least one of the following fields and values ​​is missing in the verification event data: business event number, business event name, business occurrence time, result confirmation status, or unique business result number, the corresponding record is moved to the field verification pool.

[0043] For event data, based on the attribution observation window and the platform's allowed lateness time, it is determined whether the time difference between the arrival time and the platform's original occurrence time exceeds the platform's allowed lateness time; if it exceeds the platform's allowed lateness time, it is transferred to the late event pool.

[0044] For verification event data, the time difference between the arrival time and the business occurrence time is determined based on the verification completion boundary. If it does not exceed the verification completion boundary, it is retained as a record to be supplemented. If it exceeds the verification completion boundary and the key verification record has not yet arrived, it is used as the basis for insufficient verification in subsequent status determination.

[0045] For duplicate data, event data is first determined to be duplicated based on the platform event number; verification event data is first determined to be duplicated based on the business event number. If the business event number is missing, then the unique number field and value of the business result are used to determine if duplicates are duplicated. If subsequent records with the same number only have a status field added, the added status value is retained; if the content is completely duplicated, it is only marked as duplicate and will not form a new basis for inclusion.

[0046] To ensure that subsequent steps can be directly invoked, the input for this step consists of the delivery event data returned by the advertising platform and the verification event data generated by the business system; the intermediate quantities are the original event pool, the verification event pool, the field verification pool, the late event pool, and the records to be supplemented for verification; the exception handling method is to first check the interface status when there is no return from the platform, transfer the field verification pool when the verification event data field is missing, suspend the formal processing of the current batch when the log is interrupted, transfer the late event pool when the delivery event data is late and out of bounds, and retain the first record and mark it as a copy when duplicates arrive.

[0047] In this implementation, key verification records are pre-determined in the business event caliber sheet according to business objectives. For registration objectives, key verification records are either account creation records or form submission records; if an account creation record exists, it is used as the primary verification basis; if an account creation record is missing, a form submission record is used as a supplementary verification basis. For payment objectives, key verification records are verified in a fixed order: payment completion records, payment receipts, and order records; if a payment completion record exists, it is used as the primary verification basis; if a payment completion record is missing but a payment receipt exists, the payment receipt is used as a supplementary verification basis; if both a payment completion record and a payment receipt are missing, an order record is used as an auxiliary verification basis, used to assist in confirming the corresponding payment link. For lead objectives, key verification records are used in a fixed order: lead confirmation records, customer service confirmation records, and form submission records; if a lead confirmation record exists, it is used as the primary verification basis; if a lead confirmation record is missing but a customer service confirmation record exists, the customer service confirmation record is used as a supplementary verification basis; if both a lead confirmation record and a customer service confirmation record are missing, a form submission record is used as a supplementary verification basis. If at least one of the following fields and values ​​is missing in the verification event data: business event number, business event name, business occurrence time, result confirmation status, and unique business result number, the corresponding record will be transferred to the field verification pool. Records awaiting verification are retained in the verification event pool and marked as awaiting verification. The first duplicate record is based on the first arriving record; subsequent duplicate records only have their status field supplemented, without changing the original occurrence time or original number. The observation window is used to form the current processing batch, and the settlement window is used to form the boundary between supplementary receipts and historical supplementary receipts. When the clue number is missing, a temporary unique business result number value is formed by concatenating the business occurrence time, session tag, and business page tag corresponding to the form submission time in a fixed order of "business occurrence time + separator + session tag + separator + business page tag," and its corresponding field is recorded as the temporary unique business result number field.

[0048] Through the above processing, step S1 forms the original event pool and verification event pool that are directly used in step S2, and the access entry marker, session marker, user marker, result confirmation status, observation window, settlement window, key field range, and supplementary splicing basis are all clearly defined.

[0049] The attribution observation window, continuous observation window, and recovery verification observation window are all divided by a fixed natural time window registered before the launch of the deployment task, and remain unchanged within the same deployment task cycle; when adjustments are made, they are re-registered with a new version number, and only apply to the newly added batches after the adjustment.

[0050] S2. Organize the data from the delivery event and the verification event according to the unified time, event, and identification standards, and form an evidence package around the business results. The specific implementation is as follows: The data in the original event pool and verification event pool formed in step S1 are organized according to a unified time caliber, a unified event caliber, and a unified identifier caliber, and evidence packages are formed around the business results so that cross-platform association, identification of attribution contention events and insufficient verification events can be directly performed in step S3.

[0051] First, a unified time caliber is established. The unified time caliber uses the business's unified time zone as the sole benchmark. For each event data in the original event pool, the original occurrence time and original time zone of the platform are read first, and then converted into a unified event time according to the time zone rules in the platform's access list; for each verification event data in the verification event pool, the business occurrence time is read and a unified verification time is formed according to the business's unified time zone.

[0052] If the original event time on the platform lacks hours, minutes, and seconds, and only has the date, the event data will enter the daily record stream and will not be processed at the minute level in the observation window. If the original time zone on the platform is missing, the default time zone pre-registered in the platform's access list will be used to fill in the gaps. If the converted unified event time is significantly abnormal and exceeds the platform's allowed lateness time, the record will be recorded as a time anomaly and will not be included in the standard event record. Through this process, subsequent judgments on the chronological order of events such as clicks, arrivals, registrations, orders, and payments will all be based on the unified time standard.

[0053] After standardizing the timeline, standardizing the eventline will be performed next. The standardizing eventline uses a pre-established event mapping sheet. The event mapping sheet maps the platform's original event names and the business's original event names to standardized event names. The event mapping sheet is created before the deployment task starts and is written to the corresponding event mapping item in the business event standard sheet or a separate mapping list; it remains fixed within the same deployment task cycle. If adjustments are necessary, a new version number is used for re-registration, and only the newly added records after the adjustment take effect; existing standard event records, existing evidence packages, and existing handling results are not retroactively changed.

[0054] For example, on the platform side, the first launch, activation completion, and activation success are uniformly corresponding to activation events; on the business side, account creation and registration completion are uniformly corresponding to registration events; successful form submission and successful lead confirmation are uniformly corresponding to lead confirmation events; on the platform side, successful transaction, purchase completion, and successful payment are uniformly corresponding to payment candidate events; payment candidate events refer to payment-related candidate results that have been returned by the platform side as payment-related conversion signals, but have not yet been validated based on the business side's payment completion record, payment receipt, or payment number.

[0055] Payment candidate events are only considered as business results that can proceed to subsequent processing after being verified by the business side. If a payment completion record is missing but a payment receipt or payment number that corresponds to the business result of the corresponding center exists, the payment receipt or payment number is used as a supplementary verification basis. If the payment completion record, payment receipt, and payment number are all missing, the payment candidate event status is maintained and it is not used directly as a valid business result.

[0056] If a given event name cannot be found in the event mapping sheet, the record is marked as an unexplained record and will not be included in the standard event record statistics. This process unifies the different naming conventions for the same type of event across different platforms, preventing inconsistencies in event names from affecting subsequent association determinations.

[0057] After standardizing event definitions, standardizing identifier definitions will be performed next. Since different platforms offer inconsistent tagging fields, this implementation uses a hierarchical identifier chain.

[0058] The hierarchical identifier chain, from strongest to weakest, consists of: unique business result number field and value, order number, lead number, user tag, access entry tag, session tag, platform click tag, platform device tag, and auxiliary tag formed by concatenating network address, delivery region, and unified event time in a fixed order of "network address + separator + delivery region + separator + unified event time".

[0059] During the data processing, the first-level candidate association key is formed using the unique ID field and value of the business result. If the unique ID field and value of the business result are missing, the order number and lead number are then considered. If the order number exists, it is used to form the second-level candidate association key. If the order number is missing but the lead number exists, the lead number is used to form the second-level candidate association key. If the second-level candidate association key still cannot be formed, the user tag, access entry tag, and session tag are then considered in sequence to form the third-level candidate association key. If the third-level candidate association key is missing, the platform click tag is used to form the fourth-level candidate association key. If the fourth-level candidate association key is missing, the platform device tag is used to form the fifth-level candidate association key. If the platform device tag is missing, an auxiliary tag formed by concatenating the network address, delivery region, and unified event time in a fixed order of "network address + separator + delivery region + separator + unified event time" is used to form the fifth-level candidate association key.

[0060] Each record retains candidate association keys and their levels. When performing cross-platform associations in the future, higher-level candidate association keys will be used first.

[0061] If a single record forms multiple candidate association keys of the same level, all of them will be retained initially. In subsequent tracing, the candidate association key that directly corresponds to the unique identifier field of the business result, order number, or lead number will be prioritized. If candidate association keys of the same level point to different links and their priority cannot be determined at present, the record will be marked as a record pending review and will not be directly used as the basis for a single link. If no candidate association keys can be formed, the record will be marked as a weakly associated record and will only be kept for observation within the platform, not directly participating in cross-platform competition judgment.

[0062] After processing with standardized time, event, and identifier definitions, a standard event log is created. The standard event log uniformly retains the following information: platform source, account number, campaign number, ad group number, creative number, landing page version number, standardized event name, standardized event time, candidate association key, candidate association key level, targeting region, device type, original event number, processing status, and packaged status.

[0063] In this embodiment, to facilitate subsequent cross-platform association, attribution correction, and evidence level determination, the candidate association key levels are further fixed as follows: Level 1 and Level 2 candidate association keys are uniformly recorded as high-level candidate association keys, Level 3 candidate association keys are uniformly recorded as medium-level candidate association keys, and Level 4 and Level 5 candidate association keys are uniformly recorded as low-level candidate association keys.

[0064] Among them, the first-level candidate association key formed by the unique number field and value of the business result is used first to directly lock the central business result and its corresponding link; the second-level candidate association key formed by the order number or lead number is used to supplement the locking of the payment link or lead link when the unique number field of the business result is missing; the third-level candidate association key formed by the user tag, access entry tag or session tag is used to perform intermediate-level association of business results within the same access link when the unique business result number, order number or lead number is not obtained; the fourth-level candidate association key formed by the platform click tag, and the fifth-level candidate association key formed by the platform device tag or the auxiliary tag formed by concatenating network address, deployment region and unified event time in a fixed order, are only used as the basis for low-level association.

[0065] In subsequent steps, when multiple candidate links coexist, the higher-level candidate association keys are compared first, followed by the mid-level candidate association keys, and finally the lower-level candidate association keys. Links formed solely through lower-level candidate association keys are not used as the sole basis for exclusive attribution, nor are they used as the sole basis for confirmation by the attribution competition platform.

[0066] If multiple candidate association keys are generated for the same standard event record within the current processing batch, all candidate association keys and their corresponding levels are retained and written into the standard event record in descending order of level. If multiple candidate association keys have the same level, the one generated earlier is used as the current primary candidate association key for that record. When the generation times are the same, high-level candidate association keys prioritize comparing the number of non-empty items in the unique number field and value of the business result, order number, and lead number; medium-level candidate association keys prioritize comparing the number of non-empty items in the user tag, access entry tag, and session tag; and low-level candidate association keys prioritize comparing the number of non-empty items in the platform click tag, platform device tag, network address, delivery region, and unified event time. If the number of non-empty items is still the same, all candidate association keys of the same level are retained, and the record is marked as a record to be reviewed. The current primary candidate association key is not directly specified, and the remaining candidate association keys are retained as backup candidate association key information.

[0067] The "Organization Status" describes the data integrity during the organization phase, uniformly employing five categories: Normal Awaiting Verification, Awaiting Explanation, Time Anomaly, Weak Association, and Awaiting Supplementary Evidence. The "Packaging Status" describes whether the record meets the conditions for entering the evidence package formation process. The "Packaging Status" only indicates whether the record can participate in the evidence package formation, not that the evidence package is complete.

[0068] If a standard event record corresponds only to an exposure event, click event, or arrival event, and has not yet formed a link with any business result, the package status is recorded as incomplete; if a standard event record can be traced back to a specific business result through the candidate association key, the package status is recorded as ready for packaging. With this setting, the basic objects used in step S3 are uniformly standard event records and evidence packages, and the filtering is no longer repeated at the original field level.

[0069] When forming an evidence package around business outcomes, the focus is on tracing back to the business outcomes whose confirmation status is "confirmed" in the verification event pool. In this case, business outcomes uniformly refer to one or more of the following: registration events, lead confirmation events, order placement events, and payment events.

[0070] If the same user generates multiple business results within the same observation window, the results will be split into multiple evidence packages based on the unique ID field and value of the business results. If the unique ID field and value of the business results are missing, a temporary split key will be formed by concatenating the unified timestamp and session tag corresponding to the time the business results occurred in a fixed order of "unified timestamp + separator + session tag". The evidence packages will be split based on this temporary split key. If the temporary split key is repeated, a business page tag will be added as a distinguishing item. Multiple business results will not be merged into the same evidence package.

[0071] When forming the evidence package, the business result record is used as the central record, and then the access entry record, session record, ad click record, arrival record, and landing page version record are traced back. If the current business objective is registration and payment, the evidence package should retain at least the business result record, access entry record, session record, platform click record, and landing page version record; if the current business objective is lead generation, the evidence package should retain at least the business result record, form access record, platform click record, and access entry record. When tracing the evidence package, high-level candidate association keys are used first. If high-level candidate association keys are insufficient, low-level candidate association keys are used to supplement the link.

[0072] Each evidence package retains the following information: evidence package number, central business result number, central business result type, evidence chain start time, evidence chain end time, associated platform set, link integrity status, and current verification status.

[0073] The starting time of the evidence chain is the earliest of the following: the access entry record time, the platform click record time, and the arrival record time within the evidence package. The ending time of the evidence chain is the occurrence time of the central business result record. If the central business result has not yet been finally confirmed, the ending time of the evidence chain is the time of the last verification record currently received.

[0074] If the same business result can only be traced to one platform, then only that platform is retained in the associated platform set; if the same business result can be traced to multiple platforms, then all platforms are retained in the associated platform set, providing a basis for step S3 to identify attribution contention events. If the business result truly exists, but cannot be traced to any of the access entry records, session records, and platform click records, then the evidence package is recorded as having an incomplete link state; if the business result is still within the verification completion boundary registered in the business event caliber sheet, and the key verification records are not yet complete, then the evidence package is recorded as having a pending verification state. The incomplete link state and the pending verification state correspond to the two situations of missing links and incomplete verification, respectively, and the two are not used interchangeably.

[0075] To ensure the current verification status has a definite meaning, it is fixedly divided into three states: pending verification, verified, and supplementary verification completed. After an evidence package is formed, if the corresponding central business result is still within the verification completion boundary, and the payment completion record, result confirmation status, or other key verification records are not yet complete, the evidence package is recorded as pending verification. If the corresponding central business result has already formed a business result record with a confirmed result status, and there are no link conflicts, peer candidate association key conflicts, or version conflicts in the evidence package, the evidence package is recorded as verified. If the evidence package was originally in the pending verification or review status, and subsequently receives a supplementary verification record, supplementary link record, or a clear conclusion from the automatic review process in a later batch, and completes the status update accordingly, the evidence package is recorded as supplementary verification completed. The current verification status reflects the verification progress of the evidence package itself and does not replace the event status in step S3.

[0076] To ensure full transparency in this step, the input quantities, intermediate quantities, and exception handling methods are further clarified as follows: Input quantities include event data from the original event pool, verification event data from the verification event pool, platform access lists, and business event caliber sheets; intermediate quantities include unified event time, unified event name, candidate association keys, candidate association key levels, standard event records, and evidence packages; exception handling methods are as follows: if the original time is missing precise hours, minutes, and seconds, it only enters the daily record stream; if the original time zone is missing, the default time zone is used; if the original event name has no mapping item, it is recorded as a record to be explained and not included in the standard event record statistics; if all candidate association keys are missing, it is recorded as a weakly associated record; if candidate association keys at the same level conflict and their priority cannot be determined, it is recorded as a record to be reviewed; if the business result link is insufficient, it is recorded as an incomplete link state; if key verification records are not all present but are still within the verification completion boundary, it is recorded as a state to be supplemented. Through the above processing, step S2 outputs standard event records and evidence packages, providing a unified, continuous, and traceable input basis for step S3.

[0077] S3. Based on the evidence package, perform cross-platform association, identify attribution contention events and insufficient validation events, and transfer the corresponding events to the segregated ledger to form a segregated observation relationship. The specific implementation is as follows: Based on the standard event records and evidence packages generated in step S2, cross-platform association is performed to identify attribution contention events and undervalidated events, and the corresponding events are transferred to the segregated ledger so that attribution correction is performed only for events not yet in the segregated ledger in step S4. Specifically, cross-platform association groups are first established using evidence packages as the basic processing unit. These groups are formed around the same central business result, not around platform-reported attributions.

[0078] If the core business result in a certain evidence package corresponds to only one platform's click record, arrival record, or access entry record, then the evidence package forms a single-platform association group. If the core business result in the same evidence package corresponds to click records, arrival records, or access entry records of two or more platforms within the same attribution observation window, then the evidence package forms a multi-platform association group. The attribution observation window uses the attribution observation window pre-registered in the platform access list in step S1, and remains fixed within the same delivery task, without being temporarily changed during processing. By first forming single-platform association groups and multi-platform association groups, it is possible to determine whether there is inter-platform contention for different core business results, and to avoid mistakenly merging ordinary events that only occur within a platform into cross-platform contention scenarios.

[0079] After forming a multi-platform association group, the links of each platform within the same evidence package are checked sequentially. During sequential checking, the consistency of the unified event time, candidate association key level, access entry record, session tag, landing page version number, and business page tag corresponding to the central business result are checked in turn. When excluding a platform, priority is given to judging based on the consistency of the link corresponding to the high-level candidate association key, the consistency of the access entry record, and the consistency of the session tag. If a platform appears in the associated platform set, but its click record, arrival record, or access entry record does not have the same session tag with the central business result, or does not have the same access entry tag, or the landing page version number is inconsistent with the page link corresponding to the central business result, then the platform is first recorded as a weakly associated platform and is not directly used as an attribution contest platform; the weakly associated platform is retained in the associated platform set and is only used as an auxiliary reference in the subsequent step S4, and is not used as a direct basis for attribution correction.

[0080] Session continuity is verified according to the following rules: First, access entry records, arrival records, business access records, platform click records, and central business result records within the same evidence package are sorted by a unified event time. For records with session tags, a session is considered continuous if the session tags remain consistent and the record order does not involve switching to another session tag and then jumping back to the original session tag. For individual records lacking session tags, if the records before and after the missing record correspond to the same session tag, and the unified event time of the record is between the start and end times of the session, then the record is added to the record within the session and recorded as continuous. Records that do not meet the above conditions are recorded as discontinuous sessions. Platform links with discontinuous sessions cannot be directly used as high-priority attribution criteria; they can only be used as weakly related links in subsequent comparisons.

[0081] If two or more platforms can form a business result corresponding link that meets the following conditions within the same attribution observation window, and it is impossible to exclude any of the platforms based on the evidence package in the current step, then the central business result corresponding to the evidence package is recorded as an attribution contention event. The business result corresponding link should simultaneously meet the following conditions: the platform click records, arrival records, and central business result records are in a reasonable order under a unified time caliber; the access entry markers are consistent; the session markers are consistent; and the landing page version number is consistent with the business page marker, or at least one of them is consistent. In this case, the attribution contention event is defined uniformly, that is, the same central business result is simultaneously associated with two or more platforms under a unified time caliber, and it is impossible to exclude any of the platforms in the current step.

[0082] The identification of insufficiently validated events is based on the validation status on the business side, not on the strength of the platform's feedback. In practice, each evidence package is checked to see if the central business result has a validation record corresponding to its event type.

[0083] If the central business result is a registration event, but there is no account creation record in the evidence package, and the form submission record cannot be correlated with the corresponding central business result, then the central business result is recorded as a registration-type insufficient verification event; among them, the account creation record is used as the primary verification basis, and the form submission record is used as the supplementary verification basis.

[0084] If the central business result is a lead confirmation event, but there is no lead confirmation record in the evidence package, and the customer service confirmation record cannot be correlated with the corresponding central business result, and the form submission record cannot be correlated with the corresponding central business result, then the central business result is recorded as a lead-type insufficient verification event. Among them, the lead confirmation record is used as the priority verification basis, the customer service confirmation record is used as the supplementary verification basis, and the form submission record is used as the further supplementary verification basis.

[0085] If the central business result is a payment candidate event, but there is no payment completion record in the evidence package, and the payment receipt cannot be correlated with the corresponding central business result, and the payment number cannot be correlated with the corresponding central business result, then the central business result is recorded as a payment-related insufficient verification event; among them, the payment completion record is used as the priority verification basis, the payment receipt is used as the supplementary verification basis, and the payment number is used as the further supplementary verification basis.

[0086] If the central business result is still within the verification completion boundary registered in the business event caliber form in step S1, it will first be recorded as an event to be verified, and not directly as an insufficient verification event; it will only be upgraded to an insufficient verification event if the key verification record is still not completed after exceeding the verification completion boundary. With this setting, the identification boundary of the insufficient verification event is consistent with the verification completion boundary in step S1 and the evidence package status in step S2, and there will be no conflict between the two calibers.

[0087] After identifying attribution contention events and insufficient verification events, a unified event status is established. In this case, four event statuses are uniformly adopted: Normal, Pending Verification, Isolated, and Review, to describe the handling conclusions after cross-platform association. The Normal status indicates that there is no attribution contention in the central business result, and key verification records have been completed; the evidence package link can be used for subsequent attribution correction. The Pending Verification status indicates that the central business result is still within the verification completion boundary and will not be subject to final handling. The Isolated status indicates that the current evidence package constitutes an attribution contention event or insufficient verification event and needs to be excluded from the subsequent attribution correction process. The Review status indicates that the current evidence package has issues such as time inversion, session conflicts, landing page version conflicts, conflicts in peer candidate association keys, or missing fields, and a Normal or Isolated status judgment cannot be directly made in the current step; it needs to enter the automatic review process.

[0088] The event status is only used to describe the handling conclusion of step S3 and does not replace the sorting status in step S2. With this layering, step S2 is responsible for the data integrity of the sorting stage, and step S3 is responsible for the handling result of the correlation stage. The state systems of the two stages are no longer mixed.

[0089] For evidence packages under review, automatic review is performed. Automatic review takes the unified event time, candidate association keys, access entry records, session records, landing page version number, and central business result records as inputs to re-examine whether the unified time sequence between platform click records, arrival records, and central business result records is reasonable, whether the access entry tags are consistent, whether the session tags are consistent, whether the landing page version number is consistent, and whether there is a clear priority relationship among peer candidate association keys.

[0090] Automatic review is completed within the current observation window; if automatic review cannot be completed within the current observation window, it will be transferred to the next observation window for priority processing, and the review status will remain unchanged until the next observation window begins, without prematurely transferring to the normal or isolation status.

[0091] If automatic review resolves link conflicts, version conflicts, or conflicts between candidate association keys at the same level, the central business result corresponding to the evidence package is moved to a normal state. If automatic review fails to resolve the aforementioned conflicts, the central business result corresponding to the evidence package is moved to an isolated state. Automatic review does not change the original unified event name and unified event time of the central business result; it only changes the event status and the decision on whether to enter the isolated ledger. By setting up an automatic review process, the review status is no longer just a descriptive status, but a processing procedure with clear inputs, clear verification content, and clear transfer boundaries.

[0092] For events in isolation, they are uniformly recorded in the isolation ledger. The isolation ledger must retain at least the isolation number, standard event record number, evidence package number, central business result number, isolation reason, isolation time, current isolation status, allowed recovery conditions, and most recent review time. The isolation reason is fixed to one of three categories: attribution contention, insufficient verification, or unresolved review. Allowed recovery conditions are determined according to the isolation reason: if the isolation reason is attribution contention, the allowed recovery condition is that other contentioning platforms can be excluded and a unique continuous link can be retained within a subsequent preset number of consecutive observation windows; if the isolation reason is insufficient verification, the allowed recovery condition is that the corresponding key verification record is supplemented before the verification completion boundary expires or within the allowed update time, and a corresponding relationship can be formed with the current central business result; if the isolation reason is unresolved review, the allowed recovery condition is that time inversion and version issues can be eliminated after automatic review. This conflict or a conflict of candidate related keys at the same level; if the conditions for allowing recovery are met, the isolation shall be handled according to the reason for isolation: if the reason for isolation is attribution contention, the corresponding isolation record shall be transferred to the review process first. If a unique continuous link can be determined after review, the isolation shall be lifted; if the reason for isolation is insufficient verification, the isolation shall be lifted directly after supplementing the corresponding key verification record and confirming that it can form a corresponding relationship with the current central business result; if the reason for isolation is that the review has not been lifted, the isolation shall be lifted when the time inversion, version conflict or conflict of candidate related keys at the same level can be eliminated after automatic review; if the conditions for allowing recovery are not met, the isolation status shall remain unchanged.

[0093] If an evidence package is in a pending verification state, it will not be written to the segregated ledger before the verification completion boundary expires. If an evidence package is in a review state and remains pending after automatic review, it will be written to the segregated ledger. If a central business result has been marked as revoked by the business side, the original record and evidence package record will be retained, but it will not be entered into the segregated ledger, the subsequent correction ledger, or participate in subsequent strategy statistics. With this setting, the segregated ledger only accepts events that are clearly unsuitable for subsequent attribution correction, preventing premature exclusion of pending verification events that have not yet expired, and also preventing results that have been revoked by the business side from being included in subsequent links.

[0094] To enable step S5 to directly utilize the results of step S3, this step also simultaneously establishes segregated observation relationships. Segregated observation relationships describe the correspondence between events in the segregated ledger and platforms, campaigns, ad groups, creatives, landing page versions, geographic targeting, device types, and observation windows. When establishing segregated observation relationships, records in the segregated ledger are first aggregated by platform, campaign, ad group, creative, and landing page version.

[0095] If the same unit repeatedly exhibits isolated state events within a preset number of consecutive observation windows, that unit is recorded as an isolated traffic segment. If an isolated state event continuously corresponds to the same creative and the same landing page version within a preset number of consecutive observation windows, the corresponding creative and landing page version are recorded as an observed traffic segment. The aforementioned preset number is pre-registered in the platform access list in step S1 and remains fixed within the same campaign. The isolated observation relationship is only used for subsequent strategy processing and does not directly trigger budget migration or bid adjustment in this step. After this processing, step S3 outputs not only the isolated ledger but also the isolated observation relationship, enabling step S5 to directly process according to the traffic segment status without needing to re-count the distribution of isolated events.

[0096] In this implementation, the following special cases are also handled. First, if the same evidence package corresponds to multiple platforms, but one platform forms a weak link only through low-level candidate association keys, while other platforms form a complete link through high-level candidate association keys, then the platform with the weak link will not directly enter the attribution contention event determination, but will only be retained as a weakly associated platform. Second, if the same evidence package contains multiple candidate association keys of the same level, and these candidate association keys point to different platforms or different links, and the priority order cannot be determined in the current step, then the evidence package will be transferred to the review state and will not be directly recorded as normal. Third, if the central business result has been marked as revoked by the business side, then only the original record and evidence package are retained for archiving, and will no longer participate in attribution contention, insufficient verification, isolation writing, and subsequent strategy statistics. Fourth, if the evidence package link is complete, but the key verification record of the central business result arrives later than the verification completion boundary, then it will be written into the isolation ledger as an insufficient verification event first, and the decision on whether to release the isolation will be made after the conditions for allowing recovery are met.

[0097] By handling special cases uniformly, we can avoid making different judgments about the same type of anomaly in different batches.

[0098] To ensure full transparency in this step, the input quantities, intermediate quantities, and anomaly handling methods are further clarified as follows: Input quantities include standard event records, evidence packages, attribution observation windows, validation completion boundaries, and candidate association key information; intermediate quantities include cross-platform association groups, attribution contention events, undervalidation events, event states, segregated ledger records, and segregated observation relationships; cross-platform association groups are formed by the set of associated platforms within the same evidence package; attribution contention events are formed by the inability to exclude multiple platform links; undervalidation events are formed by the absence of key validation records exceeding validation completion boundaries; event states are determined by association results and validation results; segregated ledger records are formed by writing segregated states; and segregated observation relationships are formed by aggregating segregated ledger records according to platform hierarchy.

[0099] The exception handling method is as follows: evidence packages still within the verification completion boundary remain in a pending verification state and are not directly written to the segregated ledger; evidence packages with link conflicts, conflicts of peer candidate association keys, or version conflicts enter the automatic review process; platforms only associated through low-level candidate association keys are recorded as weakly associated platforms and do not directly constitute attribution contention platforms. Through the above processing, step S3 forms the segregated ledger directly used in step S4 and forms the segregated observation relationship directly used in step S5, thereby achieving stable connection in the five-step main chain.

[0100] S4. Based on the evidence package, cross-platform correlation results, and segregated ledger, attribution corrections are made for events not transferred to the segregated ledger and written into the correction ledger. The specific implementation is as follows: In this embodiment, based on the evidence package formed in step S2, the cross-platform association results formed in step S3, and the segregated ledger, events not transferred to the segregated ledger are attributed and corrected and written into the correction ledger, so that step S5 can perform budget migration and bid adjustment based on the correction ledger. In specific execution, the standard event records and evidence package are first filtered based on the segregated ledger to form a set of events to be corrected.

[0101] The set of events to be corrected only includes events that meet the following conditions: the corresponding central business result has not been written to the isolated ledger, the corresponding evidence package is not in an incomplete link state or a state awaiting supplementary verification, the corresponding central business result has not been marked as revoked by the business side, and the corresponding event status is normal. Through this filtering method, attribution correction only applies to events that have completed the preliminary screening and meet the correction conditions. Attribution correction is not performed on events in the isolated state, the state awaiting verification, the state of review, or the incomplete link state, thereby ensuring that the boundary between step S4 and step S3 is clear.

[0102] After forming the set of events to be corrected, they are first grouped according to the central business results, and then attribution corrections are performed according to the correction priority. The correction priority remains fixed within the same deployment task, prioritizing high-level candidate association keys in the evidence package, followed by medium-level candidate association keys, and finally low-level candidate association keys; within the same level, priority is given to consistency of access entry records and session start point, followed by consistency of landing page version number and business page tag.

[0103] The session start point is uniformly determined by the earliest valid access record within the same session corresponding to the current central business result. Valid access records are prioritized from the access entry record; if the access entry record is missing, the arrival record is used; if both the access entry record and the arrival record are missing, the earliest platform click record under the same session marker is used. If the links corresponding to two platforms to be corrected trace back to the same session start point time, it is considered that the session start point is consistent; if the traced session start points are different, or if neither platform can trace back to a session start point time, it is considered that the session start points are inconsistent. Session start point consistency is used to distinguish between competing links within the same session and accidentally overlapping links in different sessions.

[0104] After establishing the attribution correction platform and attribution correction hierarchy, correction criteria are simultaneously formed. These criteria are not general descriptions but rather comprised of the judgment elements actually hit during the attribution correction process. Correction criteria must include at least two of the following: the hit candidate association key level, the consistency judgment result of the access entry record, the consistency judgment result of the session start point, the consistency judgment result of the landing page version number, the consistency judgment result of the business page tag, and the time relationship between the unified event time and the occurrence time of the central business result. If fewer than two elements are hit, it is not recorded as a high or medium evidence level, but only as a basic evidence level.

[0105] When the correction attribution platform and correction attribution level of a certain central business result are directly determined by the high-level candidate association key, the high-level candidate association key and its corresponding fields are written first in the correction basis; when the correction result is formed by further comparison between candidate association keys at the same level, the consistency of access entry record, session start point, landing page version number, and business page tag are written into the correction basis in the order in which they are actually compared; when the final attribution result is formed by hierarchical collection, the collection start level, collection end level, and the reason for triggering collection are also written into the correction basis.

[0106] The correction basis in the correction ledger is stored in a structured record format, which retains at least the name of the basis item, the value of the basis item, the judgment result, and the formation time. This ensures that when subsequent upgrades, updates, reversals, and recovery verifications are performed, it is possible to trace back why the current correction record was formed, and there will be no situation where only the correction result is written without the formation path.

[0107] If a central business result is associated with only one platform, and the access entry records, session records, platform click records, and central business result records in the evidence package form a continuous link, then this central business result constitutes a single-platform, single-link business result. For single-platform, single-link business results, first check whether the platform's original attribution level is consistent with the evidence package link.

[0108] If the platform's original attribution level matches the account number, plan number, unit number, creative number, and landing page version number in the evidence package, then the platform and that level are retained as the corrected attribution result. If the platform's original attribution level does not match the evidence package's chain, then the account number, plan number, unit number, creative number, and landing page version number that actually form a continuous chain in the evidence package are used as the corrected attribution level, and the platform's original attribution level is no longer used. After this processing, the attribution correction always follows the evidence package's chain, rather than directly following the platform's self-reported attribution.

[0109] If a central business outcome is only associated with multiple hierarchical links within the same platform, then hierarchical correction will continue to be performed within the platform. During hierarchical correction within the platform, the access entry records and session start points corresponding to each hierarchical link are first compared to see if they are consistent. Then, the landing page version number is compared to see if it is consistent with the business page mark. Finally, the chronological relationship between the unified event time and the occurrence time of the central business outcome is compared.

[0110] If one of the hierarchical links simultaneously satisfies the requirements of consistent access entry records, consistent session start points, and consistent landing page version numbers, then that hierarchical level is designated as the corrected attribution level. If multiple hierarchical links meet the aforementioned conditions, the hierarchical link with the higher candidate association key level is selected first. If multiple hierarchical links have the same candidate association key level, the hierarchical link with a unified event time closer to the occurrence time of the central business result is selected first. If it is still impossible to distinguish them according to the aforementioned order, the corrected attribution level of the central business result is moved up one level until a unique level can be determined. The order of moving up one level is fixed as follows: creative number to unit number, unit number to plan number, plan number to account number, and if the account number still cannot be uniquely determined, it is moved up to the platform level.

[0111] In this way, even if there are creative level conflicts within the platform, indistinguishable results will not be forcibly attributed to a certain creative. Instead, they will converge to the smallest level that can be uniquely determined in a predetermined order, ensuring that the boundaries of the attribution results are clear.

[0112] In this step, a reasonable unified event time sequence means that the unified event time of the preceding referral record in the same central business result chain is no later than the unified event time of the subsequent business result record. When platform click records, arrival records, and central business result records exist, the unified event time of the platform click record is no later than the unified event time of the arrival record, and the unified event time of the arrival record is no later than the unified event time of the central business result record. If any one of these records is missing, only the order of the existing records is considered. If a subsequent business result record precedes a preceding referral record, and this time inversion exceeds the platform's allowed lateness time or the verification completion boundary, then this chain is not used as a high-level evidence chain and is transferred to a review state or a pending verification state.

[0113] During the attribution correction process, it is also necessary to simultaneously determine the correction attribution platform and the evidence level. The correction attribution platform is determined based on the platform to which the ultimately retained continuous link in the evidence package belongs, not directly based on the platform's original self-reported results. The existence of a central business result means that the result confirmation status in the verification event pool is confirmed, and at least one corresponding central business result record exists in the evidence package. The evidence level indicates the strength of the evidence for the current correction result; in this case, three levels are uniformly adopted: high evidence level, medium evidence level, and basic evidence level.

[0114] Evidence levels are determined in a fixed order, and only one final evidence level is retained for the same business result within the same processing batch. Specifically, the determination process first checks if the criteria for a high evidence level are met; if not, it checks if the criteria for a medium evidence level are met; if still not met, it checks if the criteria for a basic evidence level are met; if none of the three criteria are met, the result is not recorded in the correction ledger.

[0115] High evidence level corresponds to the following conditions: the result confirmation status of the corresponding central business outcome is confirmed; the evidence package contains a central business outcome record; and there exists at least one continuous link formed by high-level candidate association keys, wherein the link simultaneously satisfies the following requirements: consistent access entry marker, consistent session marker, consistent landing page version number, and reasonable chronological order of unified events. For payment targets, the evidence package is also required to contain a payment completion record, or a payment receipt or payment number that can form a one-to-one correspondence with the central business outcome. Meeting all the aforementioned conditions constitutes high evidence level.

[0116] Medium-level evidence corresponds to the following situations: Under the premise that the conditions for determining high-level evidence are not met, the confirmation status of the corresponding central business result is "confirmed"; the evidence package contains a central business result record; and there exists at least one continuous link formed by medium-level candidate association keys, wherein the link simultaneously satisfies at least one of the following: consistent access entry marker or consistent session marker, and at least one of the following: consistent landing page version number or consistent business page marker. If the aforementioned conditions are met, it is considered medium-level evidence.

[0117] Basic evidence level corresponds to the following situations: Under the premise that neither the criteria for high evidence level nor the criteria for medium evidence level are met, the confirmation status of the corresponding central business result is "confirmed"; the evidence package contains a central business result record; and the association can only be formed through low-level candidate association keys, or although it possesses some medium-level candidate association key information, only one of the access entry record, session record, landing page version number, and business page tag can remain consistent. If the aforementioned conditions are met, it is considered basic evidence level.

[0118] If a central business result is written to the correction ledger at the basic evidence level within the current processing batch, the allowed update time is from the moment the central business result is first written to the correction ledger until the verification completion boundary corresponding to the central business result expires. Within the allowed update time, if a more complete verification record or a higher level of link evidence is received, the evidence level determination is re-executed in the fixed order of high evidence level, medium evidence level, and basic evidence level. After the upgrade, only the final evidence level after the upgrade is retained, and the old level record is not retained repeatedly. Supplementary records that arrive after the verification completion boundary will no longer be used for the upgrade and update of the correction record in this batch, but will only serve as the basis for review, isolation determination, or reversal processing in subsequent batches.

[0119] If subsequent batches confirm that the center's business results should be transferred to the segregated ledger, the corresponding correction record will be reversed, and the reversal time, basis for reversal, and corresponding segregated ledger number will be recorded in the correction ledger.

[0120] To ensure full transparency in this step, the input quantities, intermediate quantities, and exception handling methods are further clarified as follows: Input quantities include the set of events to be corrected, candidate association key levels, access entry records, session records, landing page version numbers, business page tags, and result confirmation status; intermediate quantities include the correction attribution platform, correction attribution level, evidence level, and correction ledger records; exception handling methods are as follows: when a business result from the same center corresponds to multiple links of the same level and cannot be uniquely determined, it is collected level by level in a fixed order of creative number, unit number, plan number, account number, and platform level; if it still cannot be uniquely determined, it is not written into the correction ledger and is transferred to the review status.

[0121] The results of central business operations that have entered the review state are not written to the correction ledger in the current observation window; if automatic review is completed and conflicts can be resolved in the current observation window, it is determined whether to enter the normal state from the time the automatic review is completed; if automatic review is not completed in the current observation window or conflicts cannot be resolved after automatic review, the review state is maintained until the next observation window for priority processing, and the results are not directly written to the correction ledger or the segregated ledger in the current observation window, except in the case where it has been clearly stated in step S3 that the results should be written to the segregated ledger.

[0122] S5. Perform budget migration and bid adjustment based on the corrected ledger and the segregated observation relationship, and perform recovery verification after the strategy is executed. The specific implementation is as follows: In this embodiment, budget migration and bid adjustment are performed based on the correction ledger formed in step S4, and recovery verification is performed after the strategy is executed, thus forming a complete closed loop between cross-platform advertising anti-fraud and strategy optimization. In specific execution, the main granularity of strategy processing is determined in advance before the campaign is launched.

[0123] Before launching a campaign, in addition to pre-determining the main granularity of the strategy processing, the historical stability upper limit, the observation budget lower limit, the preset budget increment step size, the preset bid step size, the preset observation ratio, the preset fluctuation threshold, and the preset improvement threshold are simultaneously registered. The historical stability upper limit is determined by the highest historical stable budget value that has been verified through recovery within the baseline observation period for the corresponding strategy-processed object; if there is no historical stable version for the current campaign, the initial budget value of the campaign is used as the temporary historical stability upper limit. The observation budget lower limit is determined by multiplying the normal budget value of the corresponding strategy-processed object by the preset observation ratio. The preset budget increment step size is determined by a fixed percentage of the current normal budget value of the corresponding strategy-processed object; the preset bid step size is determined by a fixed percentage of the current bid value of the corresponding strategy-processed object.

[0124] The above parameters remain fixed within the same campaign cycle; if adjustments are necessary, a new strategy version will be registered, and the adjustments will only apply to the newly effective strategy version, without retroactively changing completed budget migrations, bid adjustments, and restoration verification results.

[0125] When the total budget at the upper level changes, the allocable budget for each strategy processing object is recalculated first, and then budget migration and bid adjustment are performed within the new allocable budget range. Before the recalculation of the total budget at the upper level is completed, the adjustment results in the previous observation window are not directly used to continue expanding the volume.

[0126] The determination of the main granularity of strategy processing follows the order of distinguishability priority, stability priority, and executability priority: when the isolation observation relationship and correction result differences between different landing page versions within the same platform can be stably distinguished, the landing page version number is selected as the main granularity of strategy processing; when the isolation observation relationship and correction result differences between different creative numbers under the same landing page version can be stably distinguished, the creative number is selected as the main granularity of strategy processing; when the sample size at the creative level is insufficient or the number of high evidence level records in the continuous observation window does not reach the preset threshold, the sample size is gradually moved up to the unit number, plan number, account number, or platform level.

[0127] In this embodiment, stable differentiation of differences means that within a preset number of continuous observation windows, two or more objects to be compared on the same platform meet one of the following conditions: First, the difference in the proportion of isolated events continuously reaches a preset difference threshold; second, the difference in the proportion of high-evidence-level records continuously reaches a preset difference threshold; third, the difference in the proportion of basic-evidence-level records continuously reaches a preset difference threshold. The aforementioned preset difference thresholds are written into the corresponding strategy parameter items before the deployment task is initiated. When the continuous observation results do not reach the preset difference threshold, or the number of high-evidence-level records for the objects to be compared within the continuous observation window does not reach the preset number threshold, the strategy processing granularity determination is not executed at that level, and the results are progressively aggregated according to a fixed order of creative number, unit number, plan number, account number, or platform level.

[0128] Once the primary granularity of strategy processing is determined, it remains fixed within the current campaign cycle. Subsequent budget migrations, bid adjustments, recovery verifications, and strategy rollbacks are all executed at this primary granularity, without cross-granularity mixed processing.

[0129] The primary granularity of strategy processing is selected from platform, account number, campaign number, ad group number, creative number, and landing page version number, and registered in the platform access list. This granularity remains fixed within the same campaign cycle. If a switch is necessary, it is re-registered with the new version number, and only applies to the newly added strategy version after the switch. Based on this, according to the primary granularity of strategy processing, the correction results within the current observation window or current settlement window are extracted from the correction ledger. These results are then combined with the isolated observation relationship formed in step S3 to form the strategy processing object. The strategy processing objects are uniformly divided into normal traffic segment, observation traffic segment, and isolated traffic segment.

[0130] The normal traffic segment refers to objects that have not been repeatedly marked by isolated observation relationships within a preset number of consecutive observation windows, and whose corresponding central business results in the correction ledger are stable, with the proportion of high-evidence-level records and medium-evidence-level records consistently remaining at or above the preset percentage. The observation traffic segment refers to objects that, although not entirely included in the isolated ledger, have a window-by-window correspondence with isolated events within a preset number of consecutive observation windows, or whose proportion of basic evidence-level records in the correction ledger reaches a preset increase relative to the previous observation window or settlement window. The isolated traffic segment refers to objects that have been clearly marked as high-risk in isolated observation relationships and whose isolated status events repeatedly occur within a preset number of consecutive observation windows. Once a policy processing object is formed, it remains fixed within the current observation window and will not be arbitrarily changed during processing. Subsequent budget migrations and bid adjustments will directly affect this policy processing object and will no longer directly adjust the original feedback results from all platforms.

[0131] After the policy processing objects are identified, budget migration is performed first. Budget migration is based on the corrected attribution results, evidence levels, uniform event names, and segregated observation relationships in the reconciliation ledger, not on the original feedback results from the platform. In practice, the budget migration-out objects are determined first, followed by the budget migration-in objects.

[0132] Budget migration targets are prioritized from isolated traffic segments. If the budget corresponding to an isolated traffic segment has been reduced to the lower limit of the observation budget, then targets from the observation traffic segment are selected as budget migration targets if the proportion of basic evidence level records is higher than the preset proportion, the decrease in the proportion of basic evidence level records compared to the previous observation window within a preset number of consecutive observation windows does not reach the preset improvement threshold, and the increase in the proportion of high evidence level records compared to the previous observation window does not reach the preset improvement threshold. The improvement threshold is written into the strategy parameter item corresponding to the platform access list or business event caliber before the launch of the campaign. The previous observation window is used as the first comparison benchmark, and the batch before the strategy version when the previous observation window was missing is used as the second comparison benchmark.

[0133] The improvement threshold is used to characterize whether the quality of the observed traffic segment has rebounded. Specifically, it is judged by whether the decline of the proportion of basic evidence level records compared to the previous observation window reaches the preset improvement threshold, and whether the increase of the proportion of high evidence level records compared to the previous observation window reaches the preset improvement threshold. When the previous observation window is missing, the corresponding batch before the policy version took effect is used as the comparison benchmark.

[0134] Budget migration targets are selected from normal traffic segments first, and migration priority is determined in the following order: first, normal traffic segments with a high proportion of high evidence level records are selected; then, normal traffic segments with unified event names consistent with the current business objectives and a number of high evidence level records in the current observation window that is higher than the preset number threshold under the same strategy processing granularity are selected; finally, normal traffic segments with a change in the number of high evidence level records in a preset number of consecutive observation windows that does not exceed the preset fluctuation threshold are selected.

[0135] If multiple normal traffic segments simultaneously meet the aforementioned conditions, the budget will be preferentially migrated to the normal traffic segment whose current budget has not yet reached the historical stable upper limit. The historical stable upper limit is determined by the average budget value within the most recent consecutive stable period in the same campaign, and is pre-registered when establishing the platform access list in step S1.

[0136] In this step, a continuous stable period refers to a continuous period during which no new isolated observation relationships are added for the same strategy-treated object within a preset number of continuous observation windows, and the change in the number of high-evidence-level records in the correction ledger does not exceed a preset fluctuation threshold, while the proportion of high-evidence-level records is not less than a preset percentage. The historical stability upper limit refers to the average budget value of each observation window for the same strategy-treated object within the most recent continuous stable period. If the most recent continuous stable period does not exist, the initial budget value registered before the launch of the deployment task is used as the historical stability upper limit.

[0137] If there are no budget migration targets that meet the conditions in the current batch, the migration-out budget is retained as a budget to be allocated and will not be forcibly allocated to other strategy processing targets in the current batch. In the next observation window, the budget migration targets will be re-determined based on the updated correction ledger and segregated observation relationships.

[0138] With this setting, the budget migration is not based on a single short-term fluctuation, but rather migrates gradually along the path where the correction results are more realistic, the level of evidence is higher, and the fluctuations are smaller.

[0139] After determining the direction of budget migration, the budget migration out and budget migration in objects are determined in a fixed order, and the migration order is not changed temporarily within the same processing batch.

[0140] The budget migration targets are determined in the following order: First, all isolated traffic segments within the current processing batch are listed as the first migration sequence, and the budget is compressed sequentially from high to low according to the current budget value until the corresponding target reaches the lower limit of the observation budget; after the first migration sequence is processed, if there are still budgets to be migrated in the current batch, targets that are selected from the observation traffic segments, whose basic evidence level record ratio is higher than the preset ratio, whose basic evidence level record ratio has not decreased by the preset improvement threshold compared to the previous observation window, and whose high evidence level record ratio has not increased by the preset improvement threshold compared to the previous observation window, are listed as the second migration sequence; targets that are not included in the first or second migration sequences are not considered as budget migration targets for the current batch.

[0141] When multiple observation traffic segments exist within the second migration sequence, the migration priority is determined sequentially according to the proportion of basic evidence level records from high to low, the number of isolated state events from high to low, and the current budget value from high to low. If the previous ranking criteria are the same, the next ranking criteria are compared. Through this process, the budget migration objects always prioritize objects with higher isolation levels, more obvious improvement deficiencies, and higher current budget usage.

[0142] Budget migration targets are determined only from normal traffic segments. In practice, targets meeting all of the following conditions are first selected from all normal traffic segments as candidate migration targets: no new isolated observation relationships have been added within the current processing batch; the number of high-evidence-level records in the correction ledger exceeds a preset threshold; the proportion of high-evidence-level records is not lower than a preset percentage; the change in the number of high-evidence-level records does not exceed a preset fluctuation threshold; and the current budget has not yet reached its historical stable upper limit. Normal traffic segments that do not simultaneously meet all of the aforementioned conditions will not be considered as budget migration targets for the current batch.

[0143] The preset quantity threshold is determined based on the average number of high evidence level records in each observation window within the most recent continuous stable period under the same strategy processing granularity before the launch of the deployment task; if the most recent continuous stable period does not exist, it is determined based on the average number of high evidence level records in each observation window within the same strategy processing granularity in the test deployment sample.

[0144] When there are multiple candidate immigrants, the immigrant priority is determined in the following order: the proportion of high-level evidence records from high to low, the number of high-level evidence records from high to low, and the difference between the current budget and the historical stable upper limit from large to small. If the previous ranking items are the same, the next ranking item is compared.

[0145] If there are no candidate objects to migrate into in the current batch, the migration-out budget will remain as a budget to be allocated, and other policy-processed objects will not be forcibly migrated into in the current batch.

[0146] When migrating the budget, it is also necessary to determine the scope of the migration and the lower limit of the budget.

[0147] For normal traffic segments, if the number of high-evidence-level records in the correction ledger increases window by window within a preset number of consecutive observation windows, and no new corresponding isolation observation relationships are added, then window-by-window incremental migration is allowed. Window-by-window incremental migration is executed according to the preset budget increment step size, and each increment does not exceed the difference between the current traffic segment budget and the historical stable upper limit, and it does not fill the historical stable upper limit all at once.

[0148] For the observation traffic segment, the budget should be kept stable in the first place; if the proportion of basic evidence level records continues to increase within the preset number of continuous observation windows, or if new isolated observation relationships are added, a slight reduction can be implemented, but it should not be reduced to zero directly within a single observation window.

[0149] For isolated traffic segments, stop adding new expansion budgets and retain only the observation budget. The observation budget is used to continuously receive subsequent data and complete recovery verification, and is not used to actively expand the traffic scale. The lower limit of the observation budget is determined by multiplying the normal budget by a preset observation ratio, and is pre-registered before the launch of the same campaign. In this way, the subsequent verification link will not be completely cut off due to a single anomaly, nor will the budget be added due to a short-term increase in the platform's apparent results.

[0150] Bid adjustments are performed after the budget migration is complete. Bid adjustments are interconnected with but not confused with the budget migration. Bid adjustments are also based on reconciling ledgers and isolating observation relationships.

[0151] For normal traffic segments, if the number of corresponding center business results displayed in the correction ledger increases window by window within a preset number of continuous observation windows, and the change in the number of high evidence level records does not exceed the preset fluctuation threshold, and the current budget has not yet reached the historical stable upper limit, then it is allowed to increase the bid by the preset bid step size; the preset bid step size remains fixed in the same campaign and will not be changed temporarily in the middle of the process.

[0152] For the observed traffic segment, the bidding priority remains unchanged; if the proportion of basic evidence level records increases within a preset number of consecutive observation windows, or if the decrease in the proportion of basic evidence level records compared to the previous observation window does not reach the preset improvement threshold and the increase in the proportion of high evidence level records compared to the previous observation window does not reach the preset improvement threshold, the bid can be slightly reduced according to the preset bidding step size.

[0153] For isolated traffic segments, bids should be maintained or reduced, and expansion mode should not be initiated. If the proportion of basic evidence level in the correction ledger record corresponding to a certain creative ID increases window by window, even if the platform's original click volume or platform's original conversion volume increases, it will not be used as a basis for increasing the bid.

[0154] If the number of high-evidence-level records in the correction ledger corresponding to a particular landing page version decreases window by window, a price reduction can be applied to that landing page version simultaneously, and if necessary, it can be moved to the observation traffic segment in subsequent batches. In this way, bid adjustments always follow the actual results and evidence levels in the correction ledger, rather than directly following the platform's apparent performance.

[0155] After budget migration and bid adjustment are executed, a unified strategy version record is generated. The strategy version record must retain at least the strategy version number, effective date, strategy processing object, budget value before adjustment, budget value after adjustment, bid value before adjustment, bid value after adjustment, trigger basis, version status field, and current strategy status. The trigger basis must at least record the correction ledger batch, segregated observation relationship batch, and central business result type directly used in this adjustment.

[0156] The version status field is fixed as pending, effective, passed recovery verification, and rolled back; the current policy status is fixed as pending verification, effective, and rolled back.

[0157] The correspondence between the version status field and the current policy status is as follows: When a policy version record is generated but has not yet entered the first subsequent observation window, the version status field is recorded as pending activation, and the current policy status is recorded as pending verification; when a policy version has been activated but has not yet formed a conclusion of passing the recovery verification, the version status field is recorded as activated, and the current policy status is recorded as activated; after a policy version forms a conclusion of passing the recovery verification, the version status field is updated to "passed recovery verification," and the current policy status is still recorded as activated; after a policy version is rolled back, the version status field is updated to "rolled back," and the current policy status is updated to "rolled back."

[0158] At any given time, only one active version status field value and one corresponding current policy status value are allowed to be retained for the same policy version. Conflicting status records are not retained in parallel.

[0159] Budget migration is performed on a single-window, one-time adjustment basis, and the same policy processing object is not repeatedly migrated more than twice within the same observation window. For normal traffic segments, the single budget increase shall not exceed the smaller portion of the difference between the current budget value and the historical stable upper limit; for observed traffic segments, the single budget decrease shall not exceed the value obtained by multiplying the current budget value by the preset migration ratio, and the decreased budget value shall not be lower than the observed budget lower limit corresponding to the observed traffic segment; for isolated traffic segments, the budget is only allowed to be tightened to the observed budget lower limit, and shall not be further reduced to zero. After the current batch completes one budget migration, the next migration shall be executed only after the ledger and isolated observation relationship have been re-verified and corrected in the next observation window.

[0160] Bid adjustments are also executed on a single-window, one-time basis. For normal traffic segments, a single bid increase cannot exceed one preset bid step; for observed traffic segments, a single bid decrease cannot exceed one preset bid step; for isolated traffic segments, bids are only allowed to remain the same or decrease, and no increases are permitted. If the same policy-processing object simultaneously meets both the increase and decrease conditions within the same observed window, the tightening action will be executed first, and adjustments in opposite directions will not be executed concurrently in the same batch.

[0161] When a strategy has reached the historical stability upper limit, the observation budget lower limit, or the corresponding boundary in the preset guaranteed value, it stops adjusting in the current direction, only retains subsequent observation and recovery verification, and no further strong adjustments in the same direction are added within the current observation window.

[0162] The current policy status is uniformly categorized into three types: in effect, pending verification, and rolled back. Once a policy version record is generated, it remains valid within the current processing cycle. Subsequent recovery verification, upgrade adjustments, and rollback operations are all based on the policy version record, not directly on operator experience. This setup ensures that every policy action in step S5 can be traced back to the specific source of evidence and the specific batch in which it took effect, preventing situations where the same traffic segment is repeatedly adjusted in different batches without a clear explanation.

[0163] After the policy version record is generated and takes effect, the recovery verification process begins. The recovery verification follows the same processing chain from steps S1 to S4, without introducing any new judgment objects.

[0164] In practice, a new batch of event data and verification event data is first received within the continuous observation window after the strategy version takes effect. Then, steps S1 to S4 are sequentially performed to generate new standard event records, evidence packages, segregation ledgers, and correction ledgers. Finally, the new segregation ledgers and correction ledgers are compared with the corresponding batches before the strategy version took effect.

[0165] Recovery verification conclusions are determined in a fixed order, and only one conclusion is output for the same policy-processed object within the same recovery verification batch. Specifically, the determination process first checks if the recovery verification failure condition is met; if not, it checks if the recovery verification success condition is met; if still not met, it checks if the continued observation condition is met.

[0166] Failure to pass recovery verification is considered a failure in the following situations: For a given policy processing object, the number of attribution contention events increases window-by-window compared to the corresponding batch before the policy version took effect; or the number of undervalidated events increases window-by-window; or the number of high-evidence-level records in the correction ledger decreases window-by-window, and the decrease percentage compared to the corresponding batch before the policy version took effect reaches a preset decrease threshold; or the number of isolated events in the isolation ledger does not decrease, and new isolated observation relationships are added. If any of the aforementioned conditions are met, the current policy version is deemed to have failed recovery verification.

[0167] Successful recovery verification is deemed to occur under the following conditions: Without triggering the failure verification conditions, within a preset number of consecutive observation windows, the number of attribution contention events for a certain policy processing object decreases window by window compared to the corresponding batch before the policy version took effect; the number of under-verified events decreases window by window; no new isolated events are added to the isolated ledger; and the change in the number of high-evidence-level records in the correction ledger does not exceed a preset fluctuation threshold and is not lower than the number of high-evidence-level records in the corresponding batch before the policy version took effect. If all the aforementioned conditions are met, the current policy version is considered to have passed recovery verification.

[0168] Continue observing the following scenario: Provided that neither the failure to pass recovery verification condition nor the success of recovery verification condition is triggered, within a preset number of consecutive observation windows, the decrease in isolated status events in the isolated ledger for a certain policy processing object does not reach the preset decrease threshold, but the change in the number of high-evidence-level records in the correction ledger does not exceed the preset fluctuation threshold and is not lower than the corresponding number in the previous observation window. If the aforementioned conditions are met, the current policy version is considered to be in a state of continued observation.

[0169] The recovery verification conclusions are uniformly classified into three categories: passed, continue observation, and failed. Other conclusion names are not used to ensure consistency in the boundaries of subsequent strategy processing.

[0170] After the recovery verification conclusion is reached, subsequent strategies and actions will be taken based on the recovery verification conclusion.

[0171] For policy processing objects that have passed the recovery verification, maintain the current policy version; if the corresponding object is a normal traffic segment and the budget has not yet reached the historical stable upper limit, it is allowed to continue to perform small-step expansion of volume in subsequent observation windows according to the original preset budget increment step and preset bid step step.

[0172] For policy targets in the continued observation state, maintain the current budget value and current output value, do not add additional budget, and do not immediately roll back; in subsequent observation windows, continue to use the fixed order of failing recovery verification, passing recovery verification, and continuing observation to re-determine, and proceed to the corresponding conclusion when a certain condition is met.

[0173] For policy processing objects that fail the recovery verification, immediately stop the current policy version from taking effect; if the current policy version has a previous stable policy version, revert to the previous stable policy version; if the current policy version does not have a previous stable policy version, revert to the preset backup policy version; after the rollback is completed, update the current policy status to "rolled back", and re-enter the recovery verification in the next observation window with the rolled-back policy version.

[0174] When the recovery verification result is unsuccessful, first determine if a previous stable policy version exists in the current policy version. If a previous stable policy version exists, revert to the previous stable policy version and restore the budget value, output value, and traffic segment status corresponding to that previous stable policy version. If no previous stable policy version exists, revert to the preset safety net policy version and restore the budget value, output value, and traffic segment status corresponding to that preset safety net policy version. Regardless of whether reverting to a previous stable policy version or a preset safety net policy version, the existing isolation observation relationship is maintained, and the isolation traffic segment mark or observation traffic segment mark is not automatically removed due to the revert. The state transition between normal traffic segments, observation traffic segments, and isolated traffic segments is based on the recovery verification result and changes in the isolation observation relationship, and does not directly transition across two state levels within the same observation window. The same policy processing object maintains only one traffic segment status within the same observation window, and subsequent state changes take effect from the next observation window, without repeatedly switching traffic segment status within the current observation window.

[0175] The observation traffic segment is converted to the normal traffic segment on the premise that the recovery verification conditions are met continuously; the isolation traffic segment is converted to the observation traffic segment on the premise that no new isolation status events are added and the number of records of medium evidence level or above increases window by window; the observation traffic segment is converted to the isolation traffic segment on the premise that a new isolation observation relationship is added or the recovery verification conditions are met continuously.

[0176] This process creates a closed loop between verification and policy rollback, preventing situations where a policy version fails verification but continues to be effective.

[0177] In this implementation, the previous stable strategy version refers to the most recent historical strategy version that precedes the current strategy version, has passed recovery verification, has not added any new isolated observation relationships within its corresponding preset number of continuous observation windows, and whose change in the number of high-evidence-level records in the ledger does not exceed a preset fluctuation threshold. This previous stable strategy version serves as the priority rollback target when the current strategy version fails recovery verification. The preset safety net strategy version refers to the initial protection strategy version pre-registered before the launch of the campaign, used to provide a minimum risk rollback boundary when a previous stable strategy version does not exist. This preset safety net strategy version at least defines the basic budget configuration, basic bid configuration, preset safety net bid value, and constraint rules that prevent the isolated traffic segment from entering the expansion processing for the normal traffic segment, the observation traffic segment, and the isolated traffic segment.

[0178] The preset minimum guaranteed payout value refers to the lowest effective payout value that can be retained during the tightening process after a price reduction, rollback, or failure to pass the recovery verification. This value is pre-registered at the main granularity of the strategy processing before the launch of the campaign. When there is a basic bid configuration for the same strategy processing object, the payout value corresponding to the basic bid configuration is used as the preset minimum guaranteed payout value. When there is no independent basic bid configuration for the same strategy processing object, the lower of the historical stable payout value of the object that has recently passed the recovery verification and the initial payout value of the campaign is used as the preset minimum guaranteed payout value.

[0179] Once the preset guaranteed minimum value is registered, it remains fixed within the same campaign period. If adjustments are necessary, it must be re-registered with a new version number, and the changes will only apply to the newly added strategy version and will not affect existing strategy versions.

[0180] The aforementioned preset number of continuous observation windows, preset quantity thresholds, preset ratios, preset increases, preset difference thresholds, preset improvement thresholds, preset fluctuation thresholds, preset budget increment steps, preset migration ratios, preset bid steps, preset decrease thresholds, preset observation ratios, preset minimum value, and preset minimum strategy versions are all written into the corresponding strategy parameter items in the platform access list or business event caliber before the launch of the campaign and remain fixed within the same campaign cycle. If adjustments are necessary, they are re-registered with a new version number, and only the adjusted new strategy version takes effect, without retrospectively changing existing strategy versions.

[0181] Among them, the preset quantity threshold is used to limit the minimum number of records required to trigger the judgment of the observed traffic segment, the judgment of the isolated traffic segment, or the re-judgment of the restoration verification within the same observation window; the preset difference threshold is used to limit the minimum difference required to achieve stable differentiation between the proportion of isolated state events, the proportion of high evidence level records, or the proportion of basic evidence level records under different strategy processing granularities.

[0182] If a candidate strategy processing granularity satisfies the high-low ratio in continuous observation results, but its corresponding difference magnitude does not reach the preset difference threshold, or the number of valid records does not reach the preset number threshold, then the candidate strategy processing granularity will not be directly determined as the final strategy processing granularity. Instead, the strategy processing granularity corresponding to the previous effective strategy version will continue to be used, or it will be reverted to a finer granularity in the platform, plan, unit, creative, or landing page version for re-evaluation.

[0183] In one embodiment, the above parameters are predetermined based on historical deployment samples, test deployment samples, and continuous observation results under the same strategy processing granularity before the deployment task is initiated. The preset number of continuous observation windows can be set to 2 to 5 observation windows; the preset number threshold can be set to 3 to 20 valid correction records; the preset ratio can be set to 0.50 to 0.80; the preset increase can be set to 0.05 to 0.20; the preset difference threshold can be set to 0.03 to 0.15; the preset improvement threshold for the decrease in the proportion of basic evidence level records can be set to 0.05 to 0.15, and the preset improvement threshold for the increase in the proportion of high evidence level records can be set to 0.05 to 0.15; the preset fluctuation threshold can be set to 0.03 to 0.10; and the preset budget increment step size can be set to the current strategy. The budget value when the version takes effect is 0.05 to 0.15; the preset migration ratio can be set to 0.10 to 0.30 of the current budget value; the preset bid step size can be set to 0.02 to 0.08 of the bid value when the current strategy version takes effect; the preset drop threshold can be set to 0.05 to 0.20; the preset observation ratio can be set to 0.10 to 0.30 of the normal budget value before entering the observation traffic segment; the preset guaranteed bid value can be set to 0.20 to 0.60 of the initial bid value of the campaign, or to 0.50 to 0.90 of the most recently verified historical stable bid value.

[0184] The above parameters remain fixed within the same campaign cycle. When adjustments are made, they are re-registered with a new version number and only apply to the newly added strategy version after the adjustment.

[0185] The number of continuous observation windows, the lower limit of the observation budget, the budget migration step size, the bid adjustment step size, the improvement threshold, the fluctuation threshold, and the recovery verification threshold are all processed according to the same strategy. The statistical results of the main granularity in the historical stable delivery samples and test delivery samples are predetermined before the delivery task is started and recorded in the strategy version record. The strategy version remains fixed during its effective period, and when adjustments are made, they only apply to the newly added batches after the adjustment.

[0186] In this embodiment, the above parameters are not arbitrarily set, but correspond to different processing purposes. A preset number of continuous observation windows is used to avoid directly performing budget migration or recovery judgments based solely on short-term abnormal changes within a single observation window, thereby reducing the impact of short-term noise on policy switching. Preset ratios and preset increases are used to limit the minimum credible conditions for budget migration objects to enter the expansion processing and the expansion range of a single batch, avoiding excessive one-time expansion before the correction results have stabilized. A preset improvement threshold is used to determine whether the observed traffic segment or isolated traffic segment shows continuous improvement, so that recovery is gradual rather than a one-time recovery when the improvement conditions are met. A preset fluctuation threshold is used to limit large fluctuations in the number of high-evidence-level records, the number of isolated state events, or their corresponding proportions during the recovery verification period, preventing policy changes due to local abnormal fluctuations. The system avoids frequent switching back and forth; preset budget increment step size and preset bid step size are used to unify the scale of single changes in budget and bid adjustments, enabling budget migration and bid adjustments to proceed in batches within fixed boundaries; preset migration ratio is used to unify the budget contraction range of the observed traffic segment in a single batch, and together with the lower limit of the observed budget, it limits the budget migration boundary to avoid excessive contraction in a single batch, which would result in insufficient observation data for subsequent recovery verification; preset descent threshold is used to unify the descent judgment boundary in the recovery verification stage, ensuring that different strategy versions are compared using consistent criteria; preset observation ratio is used to retain the necessary observation budget after the normal traffic segment is converted into the observation traffic segment, avoiding the inability to continue generating verification data due to the budget being directly cleared to zero.

[0187] The preset quantity threshold is determined based on the average number of high-evidence-level records in each observation window within the most recent continuous stable period under the same strategy processing granularity; if the most recent continuous stable period does not exist, it is determined based on the average number of corresponding records in the test deployment samples. The preset decline threshold is uniformly used as the decline judgment boundary in the recovery verification phase, calculated according to the decline ratio of the corresponding batch before the strategy version took effect; the same calculation method is used to judge the number of high-evidence-level records in the correction ledger and the number of isolated events in the isolation ledger.

[0188] The proportions of high-evidence-level records, medium-evidence-level records, and basic-evidence-level records are all calculated using the total number of central business results of the current strategy's processing object within the corresponding observation window as the denominator. The increase, decrease, and fluctuation are all based on the previous observation window as the first comparison benchmark. If the previous observation window is missing, the corresponding batch before the strategy version took effect is used as the second comparison benchmark.

[0189] This implementation also handles several special cases: First, if the total budget is forcibly adjusted by the upper-level task during the current processing cycle, the allocable budget for each strategy processing object will be recalculated according to the new total budget value, and then the budget migration will be performed within the new total budget boundary. The status of the existing traffic segment will not be automatically changed due to the change in the total budget. Secondly, if a new isolation observation relationship is added to a normal traffic segment during the recovery verification period, the expansion budget for that traffic segment will be stopped immediately, and the traffic segment will be recorded as a traffic segment to be transferred to observation. The traffic segment will remain unchanged in its original state within the current observation window, and will be transferred to the observation traffic segment from the next observation window. Third, if no new isolation status events are added to a certain isolated traffic segment within a preset number of consecutive observation windows, and the number of records at the evidence level or above in the correction ledger increases window by window, then the isolated traffic segment is allowed to be downgraded to an observation traffic segment, but is not directly restored to a normal traffic segment; Fourth, if a certain strategy's target object simultaneously meets both budget migration and price reduction conditions in the same batch, the price reduction will be implemented first. The decision on whether to continue budget migration will then be based on the subsequent results of the price reduction. Significant budget increases and price hikes will not be implemented simultaneously in the same batch. By uniformly handling special cases, conflicts between budget migration and price adjustments on the same target object can be avoided.

[0190] To ensure that this step is fully disclosed, the input quantities, intermediate quantities, and exception handling methods are further clarified as follows: The inputs include the correction ledger, isolation observation relationships, historical stability upper limit, observation budget lower limit, strategy version records, and recovery verification batch data. Intermediate quantities include strategy processing objects, budget migration out objects, budget migration in objects, adjusted budget values, adjusted output values, strategy version records, recovery verification conclusions, and rollback instructions. The strategy processing objects are formed by aggregating the correction ledger and the isolation observation relationship. The budget migration objects and budget migration objects are formed by screening based on evidence level, traffic segment status and historical stability boundary. The adjusted budget value and adjusted output value are formed by preset budget increment step size, preset bid step size, budget upper and lower limits and bid adjustment rules. The recovery verification conclusion is formed by comparing the old and new correction ledgers and isolation ledgers.

[0191] After completing the budget migration and bid adjustment, generate a strategy version record for the strategy processing object corresponding to the current batch.

[0192] The strategy version record should retain at least the following fields: strategy version number, main granularity of strategy processing, strategy processing object identifier, corresponding platform number, account number, plan number, unit number, creative number, landing page version number, version generation time, version effective start time, budget value before adjustment, budget value after adjustment, value output before adjustment, value output after adjustment, current traffic segment status, budget migration source, budget migration destination, correction ledger batch number that triggered this adjustment, corresponding isolation observation relationship number, and version status field.

[0193] The version status field is fixed as pending, effective, passed recovery verification, and rolled back.

[0194] When the same policy processing object undergoes multiple budget migrations or bid adjustments within the same observation window, the policy version record corresponding to the current observation window is generated based on the last completed adjustment result. Previous ineffective records are retained but not used as the basis for subsequent recovery verification.

[0195] Subsequent recovery verification, policy rollback, and determination of the previous stable policy version will all be based on the budget value, output value, traffic segment status, and version status fields registered in the policy version record.

[0196] The exception handling method is as follows: when the total budget at the upper layer changes, the allocable budget is recalculated first, and then each traffic segment is adjusted; if the platform interface or business logs are interrupted as a whole during the recovery verification period, the current observation window will not be used as the basis for the recovery verification conclusion, and only the existing strategy version will be maintained; when the same object triggers the opposite adjustment conditions at the same time, the tightening action will be executed first, and strong adjustments in opposite directions will not be executed in parallel in the same batch. Through the above processing, step S5 uses the ledger correction as the sole strategy basis and recovery verification as the closed-loop verification, thereby completing the final closure of the five-step main chain.

[0197] During this step, platform feedback results, business-side verification results, isolated ledger records, correction ledger records, strategy version records, and recovery verification batch data are all written to the corresponding processing logs according to a unified time caliber. Budget migration instructions, bid adjustment instructions, rollback instructions, and stop expansion instructions are all written to the strategy execution log using the strategy processing object number, strategy version number, effective time, and execution result as the smallest filing unit. During subsequent recovery verification, only newly added log records corresponding to the same strategy processing object number after the strategy version's effective time are read; historical records already used to form the correction and isolated ledgers before the strategy version's effective time are not repeatedly retrieved. By archiving ledger results, strategy instructions, and recovery verification batch data according to a unified time caliber, it is ensured that budget migration, bid adjustment, recovery verification, and strategy rollback use traceable results from the same processing loop, avoiding strategy misadjustments caused by mixing data from different batches.

[0198] In a processing batch, the policy processing objects are first divided into normal traffic segments, observation traffic segments, and isolated traffic segments based on the correction ledger and isolation observation relationship; For normal traffic segments that meet the budget migration conditions, the adjusted budget value is formed based on the budget value when the current strategy version takes effect and the preset budget increment step size, and the adjusted outgoing value is formed based on the outgoing value when the current strategy version takes effect and the preset bidding step size. For the observed flow segments that meet the budget relocation conditions, an adjusted budget value is formed based on the current budget value and the preset relocation ratio, and the remaining budget after a single batch of relocation is not lower than the lower limit of the observed budget. For isolated traffic segments that meet the downgrade conditions, they will be converted into observation traffic segments starting from the next observation window, and the corresponding budget value will be limited to above the lower limit of the observation budget. After completing the budget migration and bid adjustment, a strategy version record is generated. Within a preset number of continuous observation windows after the policy version record takes effect, perform recovery verification based on the newly formed isolated ledger and correction ledger; If the recovery verification result is successful, maintain the current strategy version; if the recovery verification result is unsuccessful, if a previous stable strategy version exists, revert to the previous stable strategy version; if no previous stable strategy version exists, revert to the preset backup strategy version.

[0199] When the budget value has reached the lower limit of the observation budget, the upper limit of historical stability, or the basic budget configuration boundary corresponding to the preset minimum guarantee strategy version, no further budget adjustments will be made in the same direction. When the output value has reached the preset minimum output value or the maximum expansion output value allowed by the current strategy version, no further bid adjustments will be made in the same direction. After reaching the boundary, the corresponding strategy processing object will only re-verify and correct the ledger and isolate the observation relationship in the next observation window. It will not be directly presumed that the recovery verification has passed or failed simply because the boundary has been reached.

[0200] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0201] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented in whole or in part by a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions of the embodiments of this application are implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted wirelessly or wiredly from one website, computer, server, or data center to another website, computer, server, or data center. Wired methods include optical fiber, twisted pair, coaxial cable, etc. Wireless methods include infrared, microwave, etc. Available media include any available media that can be accessed by a computer or data storage devices such as servers and data centers that contain one or more sets of available media. Available media can be magnetic media (floppy disks, hard disks, magnetic tapes), optical media (DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0202] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for anti-fraud and strategy optimization in cross-platform advertising, characterized in that, include: S1. Receive campaign event data from multiple advertising platforms and receive corresponding verification event data from the business side. S2. Organize the data on the delivery event and the verification event according to the unified time standard, unified event standard and unified identification standard, and form an evidence package based on the business results; S3. Based on the evidence package, perform cross-platform association, identify attribution contention events and insufficient verification events, and transfer the corresponding events to the segregated ledger to form a segregated observation relationship; S4. Based on the evidence package, cross-platform correlation results, and segregated ledger, attribution corrections are made for events that have not been transferred to the segregated ledger and written into the correction ledger; S5. Perform budget migration and bid adjustment based on the corrected ledger and the isolation observation relationship, and perform recovery verification after the strategy is executed.

2. The method for cross-platform advertising anti-fraud and strategy optimization according to claim 1, characterized in that, S1 includes: Establish a platform access list and a business event definition sheet for the same deployment task; The platform access list should include the platform name, account number, plan number, unit number, creative number, landing page version number, delivery region, device type, platform original time zone, data feedback frequency, platform event naming rules, platform click tag field, platform device tag field, platform attribution tag field, attribution observation window, platform allowable late time, platform delivery status field, and platform data version field. The business event caliber form should include the business target type, business unified time zone, verification event name, result confirmation caliber, verification completion boundary, unique business result number field, access entry mark source, session mark source, user mark source, and business side log source. The platform access list and business event caliber list remain fixed within the same deployment task cycle. When adjustments are made, they are re-registered with the new version number, and only the newly added records after the adjustment take effect.

3. The method for anti-fraud and strategy optimization in cross-platform advertising as described in claim 1, characterized in that, S1 also includes: Write the event data to the original event pool and write the verification event data to the verification event pool. The event data in the original event pool should retain at least the following fields: platform source, platform event number, platform original event name, platform original occurrence time, platform original time zone, account number, campaign number, unit number, creative number, landing page version number, platform click tag, platform device tag, platform attribution tag, network address, delivery region, device type, platform feedback status, and platform data version. The verification event data in the verification event pool should retain at least the following fields and values: business event number, business event name, business occurrence time, business unified time zone, access entry tag, session tag, user tag, order number, payment number, lead number, business page tag, business status, result confirmation status, unique number of business result, and single version field of business event scope; When at least one of the following fields and values ​​in the verification event data is missing: business event number, business event name, business occurrence time, result confirmation status, and unique number of business result, the data is transferred to the field pending verification pool. When event data is delayed beyond the specified limits, it is transferred to the delayed event pool. When a record arrives duplicated, the duplicate marking process is executed.

4. The method for anti-fraud and strategy optimization of cross-platform advertising as described in claim 1, characterized in that, S2 include: Using the unified business time zone as the sole time benchmark, we will perform unified time standardization on both event delivery data and verification event data. The platform's original event names and business's original event names are standardized using a pre-established event mapping sheet. The unified identification criteria are organized using the unique business result number field and value, order number, lead number, user tag, access entry tag, session tag, platform click tag, platform device tag, and auxiliary tags formed by combining network address, delivery region and unified event time. After completing the aforementioned organization, a standard event log is generated.

5. The method for anti-fraud and strategy optimization in cross-platform advertising as described in claim 4, characterized in that, S2 also includes: Perform retrospective analysis on standard event records according to candidate association key levels to form an evidence package around the confirmed core business results; Each evidence package should retain at least the evidence package number, central business result number, central business result type, evidence chain start time, evidence chain end time, associated platform set, chain integrity status, and current verification status; When the same user generates multiple business results within the same observation window, the evidence package is split first based on the unique number field and value of the business result. If the unique number field of the business result is missing, the evidence package is split based on the time of occurrence of the business result and the session tag. Payment candidate events will only proceed to the subsequent processing procedure if a payment completion record exists in the evidence package. If a payment completion record is missing but a payment receipt or payment number exists that can correspond to the business results of the corresponding center, the payment receipt or payment number will be used as supplementary verification evidence.

6. The cross-platform advertising anti-fraud and strategy optimization method according to claim 1, characterized in that, S3 include: Establish cross-platform association groups using evidence packages as the basic processing unit; Perform a unified check on the consistency of event time, candidate association key level, access entry record, session continuity, landing page version number, and business page tag across all platform links within the same evidence package; When the business results of the same center are simultaneously associated with two or more platforms under the same time caliber and it is impossible to exclude any of the platforms, it is recorded as an attribution contention event. The situation where the verification record corresponding to the central business result is missing and exceeds the verification completion boundary is recorded as a verification insufficiency event. The verification record is determined according to the business objective type.

7. The method for anti-fraud and strategy optimization in cross-platform advertising as described in claim 6, characterized in that, S3 also includes: Event states are formed based on attribution contention events and undervalidated events; The event status is fixed as normal, pending verification, isolated, and review. Events that are in a state of isolation are written into the isolation ledger; The records in the isolation ledger are aggregated by platform, plan, unit, creative, and landing page version to form isolation observation relationships; When the same unit repeatedly experiences an isolation state event within a preset number of consecutive observation windows, the unit is recorded as an isolation flow segment. When an isolated event continuously corresponds to the same creative and the same landing page version within a preset number of consecutive observation windows, the corresponding creative and the corresponding landing page version are recorded as the observation traffic segment.

8. The method for anti-fraud and strategy optimization in cross-platform advertising as described in claim 1, characterized in that, S4 includes: The standard event records and evidence packages are filtered based on the segregated ledger to form a set of events to be corrected; The central business results in the set of events to be corrected have not been written to the isolated ledger, the corresponding evidence package is not in the state of incomplete link or pending supplementary evidence, the corresponding central business results have not been marked as revoked by the business side, and the corresponding event status is normal. Group the set of events to be corrected according to the central business results, and perform attribution correction according to the candidate association key level, access entry record consistency, session start consistency, landing page version number and business page tag consistency; When a unique attribution level cannot be determined, the attribution should be collected level by level in a fixed order: creative number, unit number, plan number, account number, and platform level.

9. A cross-platform advertising anti-fraud and strategy optimization method according to claim 8, characterized in that, S4 also includes: Based on the correction results, determine the correction attribution platform, correction attribution level, and evidence level, and record them in the correction ledger; The levels of evidence are fixed as high evidence level, medium evidence level, and basic evidence level; Evidence levels are determined in a fixed order of high evidence level, medium evidence level, and basic evidence level. Only one final evidence level is retained for the same business result within the same processing batch. Each record in the correction ledger must retain at least the correction number, standard event record number, evidence package number, central business result number, correction attribution platform, correction attribution level, unified event name, unified event time, evidence level, correction basis, and writing time. The allowed update time is the time interval from the time the corresponding correction record is written into the correction ledger to the time when the verification and completion boundary of the corresponding central business result expires. When a more complete verification record or a higher level of link evidence is received within the allowed update period, an upgrade update is performed on the corresponding correction record; When the results of central business operations are confirmed in subsequent batches to require transfer to the segregated ledger, the corresponding correction record is reversed.

10. A cross-platform advertising anti-fraud and strategy optimization method according to claim 1, characterized in that, S5 include: Before the launch of the deployment task, the main granularity of strategy processing is determined in advance, and the strategy processing object is formed by combining the correction ledger and the isolation observation relationship according to the main granularity of strategy processing; The policy processing targets are fixedly divided into normal traffic segment, observed traffic segment, and isolated traffic segment; Based on the corrected ledger and the isolation observation relationship, the budget migration out and budget migration in targets are determined. Among them, the budget migration out targets are first determined from the isolation flow segment, and then determined from the observation flow segment when the isolation flow segment reaches the predetermined observation budget lower limit. The budget migration in targets are determined from the normal flow segment, and budget migration and bid adjustment are performed. Generate strategy version records after budget migration and bid adjustments; After the policy version record takes effect, recovery verification is performed based on the isolated ledger and correction ledger formed in subsequent continuous observation windows, combined with the isolated ledger and correction ledger of the corresponding batch before the policy version took effect. If the recovery verification result is unsuccessful, and there is a previous stable strategy version that has passed the recovery verification, the current strategy version will revert to the previous stable strategy version; if there is no previous stable strategy version in the current strategy version, the current strategy version will revert to the preset backup strategy version.

Images