A seat intelligent matching method, device and medium based on show preference

Abstract

The application discloses a kind of seat intelligent matching method, equipment and medium based on viewing preference, is related to ticket resource matching field, comprising: by forming seat matching data pool, and generating preference hierarchical benchmark table and alternative acceptance benchmark table;According to seat matching data pool and preference hierarchical benchmark table, determine the preference confirmation proportion of each type of viewing preference of user, in combination with the explicit operation record in current ticket purchase request, form rigid ticket purchase preference, priority matching preference and alternative preference;According to preference processing chain and performance ticket resource data, match in seat combination unit, and generate hierarchical alternative seat combination when first choice seat combination is insufficient;According to real-time transaction state data, carry out seat locking inventory feedback switching, generate recommended seat set;Show recommended seat set and write back user operation feedback.The application realizes viewing preference layering, seat combination substitution and real-time transaction state linkage seat intelligent matching.

Description

Technical Field

[0001] This invention relates to the field of ticketing resource matching, and in particular to a method, device and medium for intelligent seat matching based on audience preferences. Background Technology

[0002] With the expansion of online ticket sales for concerts, musicals, plays, and stadium performances, ticketing platforms typically rely on user accounts, order records, showtime information, ticket price zones, seating charts, seat reservations, and payment records to provide users with services such as seat selection, recommendations, adding to cart, order placement, and payment. In enterprise-level ticketing systems, seat resources need to be linked to the performance time, ticket zone, queue number, ticket price, sales batch, and real-time transaction status simultaneously. This data must be managed in conjunction with user browsing, favorites, adding to cart, and historical ticket purchase behavior to support seat display and transaction processing in high-volume ticketing scenarios.

[0003] However, existing methods still have two limitations: First, seat recommendations are mainly based on ticket price, region, or ticket availability, and there is a lack of hierarchical correlation between user historical preferences, current explicit actions, and alternative acceptance behaviors, making it difficult to distinguish between mandatory, priority, and alternative ticket purchase needs. Second, when the preferred seat is locked, pending payment, or being released, the recommendation results are not well connected with the real-time transaction status, which can easily lead to unclear order of alternative seat calls and situations where manual screening is required after multiple seat combinations fail. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a seat matching method based on audience preferences to solve the problems of insufficient audience preference stratification and inadequate linkage between seat combination substitution and real-time transaction status in existing technologies.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] In a first aspect, the present invention provides a seat intelligent matching method based on performance viewing preferences, comprising: acquiring user performance viewing behavior data, current ticket purchase request data, performance ticketing resource data, real-time transaction status data, historical recommendation display data, and historical payment result data to form a seat matching data pool; generating a preference hierarchy benchmark table and an alternative acceptance benchmark table containing a median benchmark and an upper quartile benchmark based on historical successful orders, historical recommendation display data, and historical payment result data; outputting the preference confirmation ratio of various user performance viewing preferences according to the seat matching data pool and the preference hierarchy benchmark table; and, in conjunction with the explicit operation records in the current ticket purchase request, classifying performance viewing preferences into rigid ticket purchase preferences, priority matching preferences, and alternative preferences to form a preference processing chain; and, based on the preference processing chain and performance ticketing resources... Data is matched by seat combination. First, seat combinations are filtered out based on rigid ticketing preferences. Then, seat combinations are arranged according to priority matching preferences. When the preferred seat combination is insufficient, a tiered alternative seat combination is generated based on the alternative acceptance benchmark table. Based on real-time transaction status data, the preferred seat combination and the tiered alternative seat combination are checked for status such as locked, pending payment, release countdown, sold, system reserved, and available for sale. When the preferred seat combination is unavailable, the locked seat inventory is switched according to the alternative tier, generating a set of recommended seats. The set of recommended seats is displayed, and user feedback on seat combination clicks, exclusions, adding to cart, confirming alternatives, submitting orders, payments, and refunds is collected. The feedback is written back to the seat matching data pool to update the user viewing preference tiering results, preference tiering benchmark table, and alternative acceptance benchmark table.

[0008] As a preferred embodiment of the intelligent seating matching method based on viewing preferences described in this invention, the generation of a preference stratification benchmark table and an alternative acceptance benchmark table, which includes a median benchmark and an upper quartile benchmark, includes: grouping successful payment orders within a complete historical ticketing period according to performance category, venue type, ticket price range, number of tickets purchased, and user ticketing scenario; statistically analyzing the distribution of the occurrence proportion of various viewing preferences in the valid historical successful orders of sample users; recording the median of the occurrence proportion distribution as the priority matching benchmark; and recording the upper quartile of the occurrence proportion distribution as the rigid confirmation benchmark, thereby generating a preference stratification benchmark table; and grouping performance categories according to performance category, venue type, ticket price range, number of tickets purchased, and alternative seating methods according to historical recommendation display data and historical payment result data; statistically analyzing the distribution of the alternative acceptance proportion of various alternative seating methods among sample users; recording the median of the alternative acceptance proportion distribution as the displayable alternative benchmark; and recording the upper quartile of the alternative acceptance proportion distribution as the priority alternative benchmark, thereby generating an alternative acceptance benchmark table.

[0009] As a preferred embodiment of the intelligent seat matching method based on viewing preferences described in this invention, the step of outputting the preference confirmation ratio for various user viewing preferences includes: filtering valid historical successful orders from the seat matching data pool that have complete user identifier, performance identifier, showtime identifier, ticket price range, seat area, number of tickets purchased, seat combination type, and payment success status; for ticket price range preference, consecutive seat preference, frequently selected area preference, multi-person travel preference, same ticket price area preference, and adjacent area preference, respectively, counting the number of orders that meet the corresponding viewing preferences in the user's valid historical successful orders, and taking the ratio between the number of corresponding orders and the total number of the user's valid historical successful orders as the preference confirmation ratio for that type of viewing preference.

[0010] As a preferred embodiment of the intelligent seat matching method based on performance preferences described in this invention, the step of dividing performance preferences into rigid ticketing preferences, priority matching preferences, and alternative preferences to form a preference processing chain includes: when the number of a user's valid historical successful orders reaches the minimum statistical sample size in the preference stratification benchmark table, the preference confirmation ratio of the performance preference is not lower than the corresponding rigid confirmation benchmark, and there is a clear operation record in the current ticket purchase request that is consistent with the performance preference, the performance preference is written into the rigid ticketing preference; when the number of a user's valid historical successful orders reaches the minimum statistical sample size in the preference stratification benchmark table, the preference confirmation ratio of the performance preference is not lower than the corresponding priority matching benchmark, but the current ticket purchase request does not use the performance preference as a clear restriction condition, the performance preference is written into the priority matching preference; when the number of a user's valid historical successful orders does not reach the minimum statistical sample size, a rigid ticketing preference is generated based on the clear operation record in the current ticket purchase request, and a priority matching preference is generated based on browsing, dwelling, clicking, favorite, or adding to cart behavior, and a preference processing chain is formed in the order of rigid ticketing preferences, priority matching preferences, and alternative preferences.

[0011] As a preferred embodiment of the intelligent seat matching method based on viewing preferences described in this invention, the step of matching by seat combination based on preference processing chain and performance ticketing resource data includes: when the number of ticket buyers is one, a single seat is considered as a seat combination; when the number of ticket buyers is greater than one, seat combinations of consecutive seats in the same row, seat combinations of spaced seats in the same row, seat combinations of adjacent seats in front and behind rows, and seat combinations of adjacent areas are generated based on seat number, area number, row number, column number, ticket price range, and seat combination status; basic screening of seat combinations is performed based on rigid ticket purchase preferences, eliminating seat combinations that do not meet the conditions of performance session, number of ticket buyers, ticket price range, consecutive seat demand, adjacent seat demand, actively excluded area, and platform transaction rules; and the screened seat combinations are arranged according to priority matching preferences.

[0012] As a preferred embodiment of the seat intelligent matching method based on viewing preferences described in this invention, the step of generating tiered alternative seat combinations by combining an alternative acceptance benchmark table when the preferred seat combinations are insufficient includes: based on users' historical recommendation display records and historical payment result data, counting the number of times users displayed alternatives for adjacent areas at the same ticket price, alternatives for different rows within the same area, alternatives for adjacent seats in front and behind rows, alternatives for non-contiguous seats in the same row, and alternatives for adjacent ticket price tiers, as well as the number of times payment was completed after displaying these alternatives; and determining the alternative acceptance ratio for the corresponding alternative seat method based on the ratio between the number of times payment was completed after displaying and the number of times it was displayed. When the acceptance rate of alternative seating arrangements is not lower than the priority alternative benchmark in the alternative acceptance benchmark table, a priority alternative seating combination is generated based on the alternative seating arrangements. When the acceptance rate of alternative seating arrangements is not lower than the displayable alternative benchmark in the alternative acceptance benchmark table but lower than the priority alternative benchmark, a displayable alternative seating combination is generated based on the alternative seating arrangements. When the acceptance rate of alternative seating arrangements is lower than the displayable alternative benchmark, or the number of times the user's corresponding alternative seating arrangement is displayed does not reach the minimum statistical sample size, the seating combination generated by the alternative seating arrangement is used as the alternative seating combination that requires user confirmation.

[0013] As a preferred embodiment of the seat intelligent matching method based on viewing preferences described in this invention, the step of switching the locked seat inventory according to the substitution level to generate a recommended seat set includes: using the preferred seat combination and the tiered alternative seat combination as verification units, reading the available, sold, locked, pending payment, release countdown, system reserved, and unsaleable status of all seats in each seat combination; when all seats in the preferred seat combination are in a sellable state and meet the rigid ticket purchase preference, the preferred seat combination is written into the recommended seat set; when If any seats in the preferred seating combination are sold, unsaleable, reserved by the system, locked by another party, pending payment by another party, or have not been released, the preferred alternative seating combination is called for verification. If the preferred alternative seating combination fails the real-time transaction status verification, the available alternative seating combination is called. If the available alternative seating combination still fails the real-time transaction status verification, the alternative seating combination that requires user confirmation is read. If none of the seating combinations can satisfy the rigid ticketing preference, a rematching record is generated, and candidate seating combinations are regenerated according to the original user viewing preference stratification results.

[0014] As a preferred embodiment of the intelligent seat matching method based on viewing preferences described in this invention, the step of writing feedback back to the seat matching data pool and updating the user viewing preference stratification results, preference stratification benchmark table, and alternative acceptance benchmark table includes: writing the user's clicks, exclusions, add-to-cart actions, confirmation of alternatives, rejection of alternatives, order submission, payment success, payment failure, payment timeout, order cancellation, and ticket refund completion operations for the displayed seat combinations into the user operation feedback record; writing the seat combinations with successful payments into the user's valid historical successful order set and updating the user's preference confirmation ratio for various viewing preferences; writing the alternative seat combinations with completed payments after display into the user's alternative acceptance record and updating the user's alternative acceptance ratio for the corresponding alternative seat method; after the complete ticketing cycle ends, based on newly paid successful orders, historical recommended display records, and historical payment result data, re-statistically analyzing the preference occurrence ratio distribution and alternative acceptance ratio distribution, and updating the priority matching benchmark and rigid confirmation benchmark in the preference stratification benchmark table, as well as the displayable alternative benchmark and priority alternative benchmark in the alternative acceptance benchmark table.

[0015] In a second aspect, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein when the computer program is executed by the processor, it implements any step of the seat intelligent matching method based on audience preferences as described in the first aspect of the present invention.

[0016] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any step of the seat intelligent matching method based on audience preferences as described in the first aspect of the present invention.

[0017] The beneficial effects of this invention are as follows: By processing user preferences in a hierarchical interactive manner, the current explicit operation, preference confirmation ratio, and preference hierarchical benchmark table are merged into rigid ticket purchase preferences, priority matching preferences, and alternative preferences, which are used to clarify the processing order of seat matching, thus achieving the beneficial effect of hierarchical identification of performance needs; by processing seat lock inventory feedback interactively, the transaction status verification of preferred seat combinations and hierarchical alternative seat combinations is carried out, which is used to ensure that the recommended results can enter the order placement process when the lock, pending payment, or release changes, thus achieving the beneficial effect of linkage matching between seat substitution and transaction status. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1This is a flowchart of a seating intelligent matching method based on audience preferences.

[0020] Figure 2 Flowchart for intelligent agent matching process.

[0021] Figure 3 A flowchart for preference stratification and alternative decision-making.

[0022] Figure 4 A diagram showing agent matching and timing interactions.

[0023] Figure 5 A comparison chart of seat matching success rates under different groups with varying remaining ticket percentages.

[0024] Figure 6 A comparison chart of recommendation acceptance rates under different types of ticket purchase requests. Detailed Implementation

[0025] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0026] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0027] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0028] Reference Figures 1-6 As one embodiment of the present invention, this embodiment provides a seat intelligent matching method based on audience preferences, including the following steps:

[0029] S1. Acquire user viewing behavior data, current ticket purchase request data, performance ticketing resource data, real-time transaction status data, historical recommendation display data, and historical payment result data to form a seat matching data pool. Based on historical successful orders, historical recommendation display data, and historical payment result data, generate a preference stratification benchmark table and an alternative acceptance benchmark table containing median benchmark and upper quartile benchmark.

[0030] Furthermore, the ticketing platform receives users' ticket purchase requests for target performances and collects, cleans, merges, and generates benchmarks for seat matching data, forming a seat matching data pool. The seat matching data pool includes user viewing behavior data, current ticket purchase request data, performance ticketing resource data, real-time transaction status data, historical recommendation display data, historical payment result data, preference stratification benchmark tables, and alternative acceptance benchmark tables.

[0031] User viewing behavior data comes from user operation logs and order records already recorded by the ticketing platform. This includes historical ticket purchase dates, historical ticket prices, historical number of tickets purchased, historical seat selections, historical price tier selections, historical consecutive seat purchases, historical non-consecutive seat purchases, historical adjacent seat purchases, seat map browsing records, seat area click records, price filtering records, seat addition to cart records, unpaid order records, successfully paid order records, failed payment order records, ticket refund records, favorite records, and post-performance evaluation records. For operation records generated by the same user on different devices, they are associated according to user account, device login identifier, and order identifier to form a set of viewing behavior records corresponding to the same user.

[0032] The current ticket purchase request data is derived from the real-time operation records of users after entering the target performance ticket purchase page. This includes the target performance, performance date, number of tickets purchased, the price range selected by the user, the seating area currently viewed by the user, seating areas actively excluded by the user, the seat currently clicked by the user, the cumulative time spent by the user at each price level, the number of times the user browsed each seating area, the number of times the user clicked on each seating area, the seat combinations added to the user's cart, the user's submitted requests for consecutive seats, the user's submitted requests for adjacent seats, and other seat selection restrictions submitted by the user. The current ticket purchase request data is generated into a record based on the performance project identifier, performance date identifier, user identifier, and request time.

[0033] The performance ticketing resource data comes from the ticketing resource configuration records of the target performance, including seat number, area number, row number, column number, price tier, seat's ticket area, whether the seat can be combined with adjacent seats to form a continuous seating arrangement, whether the seat is a reserved seat by the organizer, whether the seat is a seat recommended for display by the platform, whether the seat is available for sale in the current performance, the corresponding sales batch, the corresponding sales start time, and the corresponding sales restrictions. For multi-person ticket purchase scenarios, consecutive seats in the same row, spaced seats in the same row, adjacent seats in front and behind rows, and seats in adjacent areas are marked as different types of seat combination resources.

[0034] Real-time transaction status data is derived from the ticketing platform's record of seat locking, order placement, and payment processes, including seat availability, sold status, locked status, pending payment status, payment failure release status, release countdown status, system reserved status, and unsaleable status. When a seat is locked, the system records the lock start time, lock validity time, and corresponding order identifier; when a seat is pending payment, the system records the pending payment order identifier, pending payment start time, and payment deadline; when a seat is pending payment release, the system records the payment failure time and the time it re-enters the saleable area.

[0035] Historical recommendation display data comes from the ticketing platform's records of seat recommendation results displayed to users, including the recommendation display time, recommended performance, recommended showtime, recommended seating area, recommended price tier, recommended seating combination type, whether the recommendation is the preferred seating combination, whether the recommendation is an alternative seating combination, the type of alternative seating method, whether the user clicked on the recommendation, whether the user added it to their shopping cart, whether the user submitted an order, and whether the user completed payment. Historical payment result data comes from order payment records, including payment success, payment failure, payment timeout, order cancellation, and refund results.

[0036] Before forming the seat matching data pool, the collected data undergoes unified field processing. User viewing behavior data is standardized to include fields such as user identifier, performance identifier, showtime identifier, ticket price tier, seat area, number of tickets purchased, seat combination type, order status, and operation time. Performance ticketing resource data is standardized to include fields such as performance identifier, showtime identifier, seat number, area number, row number, column number, ticket price tier, seat combination status, and sales restriction. Real-time transaction status data is standardized to include fields such as seat number, order identifier, transaction status, status start time, status end time, and status change source. Historical recommendation display data is standardized to include fields such as user identifier, performance identifier, showtime identifier, recommended seat combination type, alternative seat method type, display time, click status, add-to-cart status, order submission status, and payment completion status. Data records with missing fields retain their original record identifier and are marked with the missing field type; these records are excluded from statistical processing requiring that field.

[0037] The ticketing platform generates a preference stratification benchmark table based on successfully paid orders within a complete historical ticketing period. The complete ticketing period is the timeframe from the start of ticket sales to the end of sales for that particular performance. The preference stratification benchmark table is grouped and statistically analyzed according to performance category, venue type, ticket price range, number of tickets purchased, and user purchase scenario. Performance categories include concerts, plays, musicals, variety shows, and stadium performances; venue type is determined based on seating capacity and seating arrangement; the number of tickets purchased range includes single-person purchases, double-person purchases, and group purchases; user purchase scenarios include first-time purchases, purchases of similar historical performances, purchases of tickets at the same venue, and purchases of tickets at the same price range.

[0038] It should be noted that the viewing preference types in the preference stratification benchmark table include price range preference, consecutive seating preference, frequently selected area preference, group booking preference, same-price area preference, and adjacent area preference. Price range preference indicates the price range in which successfully paid orders fall; consecutive seating preference indicates the occurrence of consecutive seats in the same row in group ticket purchase orders; frequently selected area preference indicates the seating area or ticket area range in which successfully paid orders fall; group booking preference indicates the occurrence of orders with more than one ticket; same-price area preference indicates successful payments where the price range remains the same but the seating area changes; and adjacent area preference indicates successful payments in adjacent areas other than the preferred area.

[0039] The preference stratification benchmark table uses sample users within the same group as the statistical objects. For each sample user, the proportion of each type of performance preference appearing in that sample user's valid historical successful orders is calculated. Valid historical successful orders are order records with complete user identifier, performance identifier, showtime identifier, ticket price tier, seating area, number of tickets purchased, seating combination type, and payment success status. Order records with payment failure, payment timeout, order cancellation, completed refund, or missing fields are not included in the preference stratification benchmark table's proportion statistics.

[0040] Within the same group, the platform ranks the proportions of multiple sample users corresponding to the same viewing preference type from low to high, forming the proportion distribution of that viewing preference type. The median in the ranking results is the priority matching benchmark for that viewing preference type, and the upper quartiles in the ranking results are the rigid confirmation benchmarks for that viewing preference type. The priority matching benchmark is used to subsequently determine whether a certain viewing preference can enter the priority matching preference; the rigid confirmation benchmark is used to subsequently determine whether a certain viewing preference can enter the rigid ticket purchase preference after combining with the current clear operation record.

[0041] The median is used as the priority matching benchmark because it corresponds to the middle position of the proportion of user preferences appearing within the same group, indicating the regular occurrence level of this type of performance preference across the same performance category, venue type, ticket price range, number of tickets purchased, and purchase scenario. The upper quartile is used as the rigid confirmation benchmark because it corresponds to the lower quartile position of the proportion of user preferences appearing within the same group, indicating the level of concentrated occurrence of this type of performance preference across similar purchase scenarios. Given that the performance ticketing data contains records of concentrated ticket purchases for popular shows, group purchases, concentrated orders close to the ticket release time, and a small number of abnormally high-frequency operations, the platform does not directly generate preference stratification benchmarks based on the highest, lowest, or arithmetic mean values.

[0042] The preference stratification benchmark table should at least record the benchmark table version number, performance category, venue type, ticket price range, number of tickets purchased range, user ticket purchase scenario, viewing preference type, number of sample users, number of valid orders, minimum statistical sample size, median of the proportion distribution, upper quartile of the proportion distribution, preferred matching benchmark, rigid confirmation benchmark, generation date, and applicable status. The median of the proportion distribution corresponds to the preferred matching benchmark, and the upper quartile of the proportion distribution corresponds to the rigid confirmation benchmark.

[0043] The ticketing platform generates an alternative acceptance benchmark table based on historical recommendation and payment data. This table is grouped and statistically analyzed by performance category, venue type, ticket price range, number of tickets purchased, and alternative seating arrangement. Alternative seating arrangements include adjacent seating at the same ticket price, seating in different rows within the same area, adjacent seating in front and behind rows, non-consecutive seating in the same row, and seating at adjacent ticket price levels. The alternative acceptance benchmark table is used to subsequently determine whether a particular alternative seating arrangement qualifies for display or is given priority.

[0044] The alternative acceptance benchmark table uses sample users within the same group who have experienced alternative agent displays as the statistical objects. For each sample user, the number of recommended displays and payment completions for the same alternative agent method are counted, and the alternative acceptance rate for that sample user is calculated. The number of recommended displays comes from the platform's records of showing alternative agent combinations to the user, and the number of payment completions comes from the order records where the user completed payment after the alternative agent combination was displayed. Records of only being displayed but not clicked, clicked but not added to cart, added to cart but not submitted an order, or submitted an order but payment failed are retained in the historical recommended display data but are not included in the number of payment completions.

[0045] Within the same group, the platform arranges the acceptance rates of multiple sample users for the same alternative agent method from low to high, forming a distribution of the acceptance rates for that alternative agent method. The median in the ranking results is recorded as the displayable alternative benchmark for that alternative agent method, and the upper quartile in the ranking results is recorded as the priority alternative benchmark for that alternative agent method. The displayable alternative benchmark is used to determine whether a certain alternative agent method can be included in the displayable alternative agent combination, and the priority alternative benchmark is used to determine whether a certain alternative agent method can be included in the priority alternative agent combination. Specifically, when the acceptance rate of an alternative agent method is not lower than the priority alternative benchmark, a priority alternative agent combination is generated based on that alternative agent method; when the acceptance rate of an alternative agent method is not lower than the displayable alternative benchmark but lower than the priority alternative benchmark, a displayable alternative agent combination is generated based on that alternative agent method; when the acceptance rate of an alternative agent method is lower than the displayable alternative benchmark, or the number of times the alternative agent method is displayed has not reached the minimum statistical sample size, an alternative agent combination requiring user confirmation is generated based on that alternative agent method. Both alternative agent combinations that can be displayed and alternative agent combinations that require user confirmation retain the fields for alternative agent method type, alternative acceptance ratio, referenced alternative acceptance benchmark table version number, and benchmark completion source.

[0046] The median is used as the benchmark for showcasing alternative seating options because it corresponds to the typical acceptance level of the same alternative seating option in similar ticketing scenarios, providing a statistical basis for whether the alternative seating option has the potential to be included in the showcase. The upper quartile is used as the benchmark for priority alternative seating options because it corresponds to a higher level where the acceptance rate of the same alternative seating option is more concentrated in similar ticketing scenarios, providing a statistical basis for whether the alternative seating option has the potential to be included in the priority alternative range. The acceptance rate of alternative seating options is affected by the popularity of the performance, the number of remaining tickets, the number of tickets purchased, the ticket price range, and the stage of ticket sales. The rate may vary between different performances, and the platform does not use a uniform fixed value as the benchmark for judging the alternatives for all performances.

[0047] The alternative acceptance benchmark table must record at least the benchmark table version number, performance category, venue type, ticket price range, number of tickets purchased range, alternative seating method, number of sample users, number of recommended displays, number of completed payments, minimum statistical sample size, median alternative acceptance ratio, upper quartile of alternative acceptance ratio, displayable alternative benchmark, preferred alternative benchmark, generation date, and applicable status. The median alternative acceptance ratio corresponds to the displayable alternative benchmark, and the upper quartile of the alternative acceptance ratio corresponds to the preferred alternative benchmark. The minimum statistical sample size is formed based on valid recommended display records within the same group for a complete historical ticketing period, representing the minimum amount of historical display data required for a particular alternative seating method to participate in the alternative acceptance ratio determination. Valid recommended display records should have complete user identifier, performance identifier, showtime identifier, alternative seating method, display time, and post-display payment result fields. Records in a locked, pending payment, unfinished release countdown, or with uncertain payment results are not included in this field. This field is dynamically updated with new recommended display records and payment result records after the end of the complete ticketing period and is stored in conjunction with the corresponding group, alternative seating method, and benchmark table version number.

[0048] When the number of sample users or valid orders in a certain group does not reach the minimum statistical sample size, the platform performs baseline completion according to the group level. The baseline completion order is as follows: first, retain the performance category, ticket price range, and number of tickets purchased range, and relax the venue type; if the minimum statistical sample size is still not reached, retain the performance category and number of tickets purchased range, and relax the ticket price range; if the minimum statistical sample size is still not reached, call the platform's historical full baseline under the same number of tickets purchased range. The completed baseline record is written to the corresponding baseline table, and the baseline completion source is recorded in the applicable status field.

[0049] For target performances currently on sale, order records in the pending payment, locked, or unreleased countdown states are not written to the preference stratification benchmark table and alternative acceptance benchmark table. Records of successful payment, failed payment and released, cancelled order and refunded order are written to the seat matching data pool according to their respective states. For performances that have completed their full ticketing period, the platform updates the preference stratification benchmark table and alternative acceptance benchmark table based on successful payment orders, recommended display records, and payment result records within the full ticketing period, and retains the benchmark table version number, update date, and applicable performance group before and after the update.

[0050] S2. Based on the seat matching data pool and the preference hierarchy benchmark table, output the preference confirmation ratio of various types of user viewing preferences. Combined with the explicit operation records in the current ticket purchase request, the viewing preferences are divided into rigid ticket purchase preferences, priority matching preferences, and alternative preferences, forming a preference processing chain.

[0051] Furthermore, the ticketing platform reads user viewing behavior data, current ticket purchase request data, preference stratification benchmark table, and performance ticketing resource data from the seat matching data pool. It then stratifies users' seat selection needs during the target performance ticket purchase process, generating a user viewing preference stratification result. This result includes rigid ticket purchase preferences, priority matching preferences, and alternative preferences.

[0052] Rigid ticketing preferences record the consistent ticketing conditions that must be maintained in the current ticketing request. These include the user's selected performance date, number of tickets purchased, ticketing conditions stipulated by the platform's transaction rules, the user's explicitly defined price range, seat areas actively excluded by the user, and the user's actively submitted requests for consecutive seats and adjacent seats. The performance date, number of tickets purchased, and ticketing conditions stipulated by the platform's transaction rules are directly written into rigid ticketing preferences; the price range, consecutive seat requests, adjacent seat requests, and actively excluded areas are written into rigid ticketing preferences based on the user's explicit operation record in this instance, without relying on individual historical orders for inference.

[0053] Priority matching preference records the ticket purchasing tendencies that participate in seat combination ranking after satisfying rigid ticket purchasing preferences. This includes the user's historically frequently selected price tiers, historically frequently selected seat areas, seat combination types ranked highest in historical payment success rates, seat areas ranked highest in current pageview counts, price tiers ranked highest in current cumulative dwell time, seat areas ranked highest in current click counts, and seat combinations added to cart but not yet submitted for order. Priority matching preference is used to rank candidate seat combinations and is not used as a separate condition for eliminating seat resources.

[0054] Among them, the most frequently selected fare tier in a user's history refers to the fare tier that appears most frequently in the user's valid historical successful orders; the most frequently selected seat area in a user's history refers to the seat area that appears most frequently in the user's valid historical successful orders. If multiple fare tiers or multiple seat areas appear the same number of times, the fare tier or seat area corresponding to the most recently paid successful order will be used to determine it.

[0055] The seating areas ranked highest by page views refer to those ranked first in terms of page views within the same user, for the same target performance, the same showtime, and the same ticket purchase request record, arranged from highest to lowest. If multiple seating areas have the same number of page views, the area with the most recent page view time will be used to determine the ranking. The ticket price tier ranked highest by cumulative dwell time refers to those ranked first in terms of cumulative dwell time on the corresponding page or seating area within the same ticket purchase request record, arranged from highest to lowest. If multiple ticket price tiers have the same cumulative dwell time, the tier corresponding to the most recent click or add-to-cart action will be used to determine the ranking. The seating areas ranked highest by click count refer to those ranked first in terms of click count within the same ticket purchase request record, arranged from highest to lowest. If multiple seating areas have the same number of clicks, the ranking will be based on whether an add-to-cart action occurred and the most recent click time.

[0056] The seat combination types with the highest historical payment success rates are those where, within the corresponding performance category, venue type, ticket price range, and number of tickets purchased range, payments were completed after displaying the combination of consecutive seats in the same row, spaced seats in the same row, adjacent seats in front and behind rows, and seats in adjacent areas, respectively. These ratios are then ranked from highest to lowest, and the seat combination type with the highest ratio is ranked first. If multiple seat combination types have the same ratio, the type with more display times is used to determine the success rate; if the number of display times is still the same, the type with more completed payments in the most recent complete ticketing period is used. This ratio data is derived from historical recommendation display data and historical payment result data; records of incomplete payments, payment timeouts, order cancellations, or ticket refunds are not included in the payment completion count.

[0057] The alternative preference record allows for alternative routes to be invoked when preferred seats are insufficient, locked, or unavailable. These include alternatives for adjacent areas at the same price, alternatives for different rows within the same area, alternatives for adjacent seats in front and behind rows, alternatives for non-consecutive seats in the same row, and alternatives for adjacent price tiers. The alternative preference is only used to generate alternative seat combinations and does not cover rigid ticketing preferences.

[0058] Before generating user viewing preference stratification results, the ticketing platform filters the validity of users' historical successful orders. Valid historical successful orders are those with complete user identifier, performance identifier, showtime identifier, ticket price tier, seating area, number of tickets purchased, seating combination type, and payment success status. Order records with failed payments, payment timeouts, order cancellations, completed refunds, or missing fields are not included in the preference confirmation ratio calculation.

[0059] For each type of viewing preference, the ticketing platform calculates the preference confirmation rate based on the user's valid historical successful orders:

[0060] ;

[0061] in, Indicates the user's opinion on the first The percentage of preferences confirmed for similar performance viewing preferences; This indicates that among the user's valid historical successful orders, the one that meets the criteria is... The number of orders related to viewing preferences; This represents the total number of valid historical successful orders for a user; the... Performance preferences include preferences for ticket price range, consecutive seating, frequently chosen areas, group travel, areas with the same ticket price, and adjacent areas.

[0062] Ticket price range preference This refers to the number of orders within the same fare tier from valid historical successful orders. (Continuous seating preference corresponds to...) This refers to the number of valid historical successful orders with more than one ticket and a seat combination type of consecutive seats in the same row. Frequently selected region preferences correspond to... This refers to the number of orders from valid historical successful orders where the seating area falls within the same seat area or the same ticket zone. (This also includes information related to the preference for multiple people traveling together.) This refers to the number of orders with more than one ticket in the valid historical successful orders. (This also includes regional preferences for the same ticket price.) This refers to the number of valid historical successful orders where the fare tier remained the same, the seating area changed, and payment was completed. Adjacent area preferences correspond to... This refers to the number of orders in the valid historical successful orders where the agent area is adjacent to the historical preferred area and payment has been completed. The historical preferred area is determined by the agent area that appears most frequently in the user's valid historical successful orders; if the number of occurrences is the same, it is determined by the agent area corresponding to the most recent successfully paid order.

[0063] The ticketing platform retrieves matching groups from the preference stratification benchmark table based on the performance category, venue type, price range, number of tickets purchased range, and user purchase scenario in the current ticket purchase request. Each matching group records the priority matching benchmark, rigid confirmation benchmark, minimum statistical sample size, and benchmark table version number for each performance preference type. The priority matching benchmark is derived from the median of the proportion of user preferences appearing within the corresponding group; the rigid confirmation benchmark is derived from the upper quartile of the proportion of user preferences appearing within the corresponding group.

[0064] When a user's valid historical successful orders reach the minimum statistical sample size for matching group records, and the confirmation ratio of a certain type of performance viewing preference is not lower than the rigid confirmation benchmark corresponding to that type of performance viewing preference, and there are explicit operation records in the user's current ticket purchase request that are consistent with that type of performance viewing preference, then that type of performance viewing preference will be written into the rigid ticket purchase preference. Explicit operation records include actively limiting the price range, actively submitting consecutive seat requests, actively submitting adjacent seat requests, actively excluding seat areas, and actively selecting the number of tickets to purchase.

[0065] When a user's number of valid historical successful orders reaches the minimum statistical sample size for matching group records, and the confirmation ratio of a certain type of performance viewing preference is not lower than the priority matching benchmark corresponding to that type of performance viewing preference, but the user does not explicitly use that type of performance viewing preference as a restriction condition in the current ticket purchase request, then that type of performance viewing preference will be written into the priority matching preference. For example, if the proportion of a certain price range in a user's historical successful orders reaches the priority matching benchmark, but the user does not actively limit the price range in the current request, then that price range will be written into the priority matching preference, but not into the rigid ticket purchase preference.

[0066] When the number of a user's valid historical successful orders does not reach the minimum statistical sample size for matching group records, a rigid ticketing preference is not generated based on a small number of historical successful orders. If there are clear operation records in the user's current ticketing request, the corresponding content is written into the rigid ticketing preference; if the user's current ticketing request only involves browsing, dwelling, clicking, favoriting, or adding to cart, the corresponding content is written into the priority matching preference. For performance preferences without personal historical statistical basis and without clear operation records in the current performance, the priority matching benchmark of the same group in the preference hierarchy benchmark table is used as a reference for subsequent seat combination arrangement, and is not written into the rigid ticketing preference.

[0067] User preference hierarchical interaction processing is used to handle the relationships between multiple types of preferences in the same ticket purchase request. The ticketing platform establishes a preference processing chain in the order of rigid ticket purchase preferences, priority matching preferences, and alternative preferences, and hierarchically merges conflicting or overlapping preferences.

[0068] When the number of ticket buyers is greater than one and the demand for consecutive seats has already been written into the rigid ticket purchase preference, the consecutive seat condition takes precedence over the frequently selected area condition. If subsequent candidate seat combinations cannot meet the consecutive seat condition, they will not be retained as the preferred seat combinations simply because they meet the historical frequently selected area criteria.

[0069] When the price range is already included in rigid ticketing preferences, the price range takes precedence over seat area preferences. Subsequent candidate seat combinations that exceed this price range will not be retained as preferred seat combinations simply because they belong to historically frequently selected areas or areas of focus for this browsing session.

[0070] When a user actively excludes a particular seating area, that seating area will not be included in the priority matching preference or alternative preference. Even if the seating area appears in the user's historical successful orders at a rate that meets the priority matching benchmark, or is a high-frequency transaction area in the same user group, it will not be used as a seating combination matching target for the current ticket purchase request.

[0071] When there are conflicts or overlaps between the number of ticket buyers, price range, consecutive seat demand, actively excluded areas, historically frequently selected areas, and currently viewed areas, the ticketing platform prioritizes rigid ticket purchase preferences. Priority matching preferences only participate in the ranking, and alternative preferences are only invoked when there are insufficient, locked, or unsaleable preferred seats. Areas actively excluded by users do not participate in the generation of preferred and alternative seat combinations.

[0072] After completing the user preference stratification interaction processing, the ticketing platform generates a user performance preference stratification result record. This record includes the user identifier, target performance, showtime identifier, ticket purchase request time, rigid ticket purchase preference field, priority matching preference field, alternative preference field, preference confirmation ratio field, referenced preference stratification benchmark table version number, minimum statistical sample size, benchmark completion source, current request explicit operation record, and preference processing chain sequence. The user performance preference stratification result record is written to the seat matching data pool, serving as the data basis for seat resource matching and generating alternative seat combinations.

[0073] S3. Based on the preference processing chain and performance ticketing resource data, match seats in units of seat combinations. First, filter out seat combinations according to rigid ticket purchase preferences, then arrange seat combinations according to priority matching preferences. When the preferred seat combinations are insufficient, generate hierarchical alternative seat combinations by combining the alternative acceptance benchmark table.

[0074] Furthermore, the ticketing platform reads performance ticketing resource data, user viewing preference stratification results, alternative acceptance benchmark table, and current ticket purchase request data from the seat matching data pool, and performs combined matching processing on the seat resources of the target performance to generate candidate seat combinations. Candidate seat combinations include preferred seat combinations, preferred alternative seat combinations, alternative seat combinations that can be displayed, and alternative seat combinations that require user confirmation.

[0075] The ticketing platform first combines seats in the performance ticketing resource data based on the number of people purchasing tickets in the current purchase request. When there is only one person purchasing tickets, a single seat is considered as a seat combination resource; when there are more than one person purchasing tickets, multi-person seat combination resources are generated according to seat number, area number, row number, column number, price tier, and seat combination status. Multi-person seat combination resources include consecutive seat combinations in the same row, spaced seat combinations in the same row, adjacent seat combinations in front and behind rows, and seat combinations in adjacent areas.

[0076] Consecutive seat combinations in the same row are sets of seats within the same region, row number, fare level, and consecutive column numbers, with the number of seats matching the number of ticket purchasers. Separated seat combinations in the same row are sets of seats within the same region, row number, fare level, and with column number gaps between them, with the number of seats matching the number of ticket purchasers. Adjacent seat combinations in front and behind rows are sets of seats within the same region or ticket area with adjacent row numbers, with the number of seats matching the number of ticket purchasers. Adjacent area seat combinations are sets of seats belonging to adjacent ticket areas or adjacent regions in the ticketing resource configuration record, with the number of seats matching the number of ticket purchasers. After seat combination resources are generated, the ticketing platform writes the combination type, number of seats in the combination, fare level, region number, row number range, column number range, and sales restriction fields to each seat combination resource.

[0077] The ticketing platform performs a basic screening of seat combination resources based on users' rigid ticketing preferences in the stratified results of their performance viewing preferences. Rigid ticketing preferences include the performance date, the number of tickets to be purchased, ticketing conditions limited by the platform's transaction rules, the price range explicitly defined by the user, seating areas actively excluded by the user, consecutive seat requests actively submitted by the user, and adjacent seat requests actively submitted by the user. Seating combination resources will not be included in the candidate seating combination if the performance date identifier does not match the performance date in the current ticket purchase request; if the number of seats in the seating combination resource does not match the number of tickets to be purchased; if the price range of the seating combination resource is not within the price range explicitly defined by the user; and if the seating combination resource falls within the seating areas actively excluded by the user.

[0078] When there is a demand for consecutive seats in rigid ticket purchase preferences, the ticketing platform prioritizes retaining consecutive seat combinations in the same row. Seat combinations that do not meet the condition of consecutive seats in the same row will not be included in the preferred seat combinations. When there is a demand for adjacent seats in the current ticket purchase request but no requirement for consecutive seats in the same row, adjacent seat combinations in front and behind rows and adjacent area seat combinations can be included in the candidate seat combinations, but the recommendation level needs to be determined based on the alternative preference and alternative acceptance benchmark table. The ticket purchase conditions limited by the platform's transaction rules include the maximum number of tickets that can be purchased in the same order, the number of tickets that can be purchased by the same user, sales batch restrictions, sales time restrictions, and restrictions on seats reserved by the organizer. Seat combinations that do not meet these transaction rules will not be included in the candidate seat combinations.

[0079] After completing the initial screening, the ticketing platform ranks the remaining seat combinations based on the priority matching preferences in the user's viewing preference stratification results. Priority matching preferences include historically frequently selected ticket price tiers, historically frequently selected seat areas, seat combination types with high historical payment success rates, seat areas with the most views this time, ticket price tiers with the longest dwell time this time, seat areas that were the focus of this click, and seat combinations that were added to the shopping cart but not yet submitted for order.

[0080] When a seat combination resource satisfies both the historically frequently selected seat area and the current browsing focus area, it is ranked before seat combinations that only satisfy one of these preferences. If a seat combination resource is one that has been added to the cart but not yet submitted for order, it is ranked before seat combinations with only browsing or click records. If a seat combination resource belongs to a type of seat combination with a high historical payment success rate, it is ranked before seat combinations with no historical payment success records. Priority matching preferences are only used to rank candidate seat combinations and do not change the filtering results for rigid ticket purchasing preferences.

[0081] When the number of preferred seat combinations filtered and ranked according to rigid ticketing preferences reaches the number of preferred display positions corresponding to the current page session, the ticketing platform generates a list of preferred seat combinations based on the ranking results. If the number of preferred display positions is not reached, or if the preferred seat combinations cannot cover any preferred preference field, seat combination substitution interaction is initiated. The number of preferred display positions is determined by the ticketing page display template, terminal page type, sales rules, and number of ticket buyers, and is recorded in the current ticketing request data.

[0082] When the number of preferred seat combinations is lower than the number of preferred display positions corresponding to the current page session, or when there are no seat combinations in the preferred seat combination list that satisfy any priority matching preference, the ticketing platform initiates seat combination substitution interaction processing. Seat combination substitution interaction processing takes into account the rigid ticketing preference, priority matching preference, and alternative preference from the user's performance viewing preference stratification results, and reads the substitution acceptance benchmark table to perform stratified invocation of substitutions for adjacent areas at the same ticket price, substitutions for different rows within the same area, substitutions for adjacent seats in front and behind rows, substitutions for non-contiguous seats in the same row, and substitutions for adjacent ticket price tiers.

[0083] When processing seat combination substitution interactions, the ticketing platform first reads the user's personal historical recommendation display records and historical payment result data to calculate the user's preference for the [number] seat combination. The acceptance rate of alternative seating arrangements:

[0084] ;

[0085] in, Indicates the user's opinion on the first The acceptance rate of alternative seating arrangements; This indicates that the user accepts the terms after the preferred seat becomes unavailable, insufficient, or has been replaced. The number of orders that were processed and paid for using a substitute agent; This indicates that the ticketing platform displays the ticket to the user. Number of times the alternative seating method was used; Alternate seating options include adjacent area substitution with the same fare, substitution of different rows within the same area, substitution of adjacent seats in front and behind rows, substitution of non-consecutive seats in the same row, and substitution of adjacent fare levels.

[0086] The ticketing platform retrieves matching groups from the alternative acceptance benchmark table based on the performance category, venue type, ticket price range, number of tickets purchased range, and alternative seating method corresponding to the current ticket purchase request. The matching groups record and display the alternative benchmark, preferred alternative benchmark, minimum statistical sample size, and benchmark table version number. The alternative benchmark is derived from the median of the alternative acceptance rate among sample users within the corresponding group; the preferred alternative benchmark is derived from the upper quartile of the alternative acceptance rate among sample users within the corresponding group.

[0087] When the number of times a user has historically displayed a particular alternative agent method reaches the minimum statistical sample size recorded in the alternative acceptance benchmark table, and the alternative acceptance rate for that agent method is not lower than the priority alternative benchmark, that alternative agent method is added to the priority alternative call scope. The priority alternative call scope is used to generate priority alternative agent combinations.

[0088] When the number of times a user has historically displayed a particular alternative agent method reaches the minimum statistical sample size, and the acceptance rate for that alternative agent method is not lower than the displayable alternative benchmark but lower than the priority alternative benchmark, that alternative agent method is added to the displayable alternative call range. The displayable alternative call range is used to generate displayable alternative agent combinations, and the alternative method identifier must be retained when displaying them.

[0089] It should be noted that when generating alternative seating combinations, ticketing platforms must not exceed the rigid ticketing preferences in the user's viewing preference stratification results. When the price range is already written into the rigid ticketing preferences, alternatives for adjacent price tiers will not be included in the priority alternative seating combinations. They will only be included in the alternative seating combinations requiring user confirmation if the user's current ticketing request explicitly allows for alternatives for adjacent price tiers. When consecutive seat requirements are already written into the rigid ticketing preferences, alternatives for non-consecutive seats in the same row will not be included in the priority alternative seating combinations. They will only be retained as alternative seating combinations requiring user confirmation if the preferred seating combination and other consecutive seat alternative combinations are insufficient. When actively excluded areas are already written into the rigid ticketing preferences, these areas will not participate in the generation of adjacent area alternatives for the same price, alternatives for seats in different rows within the same area, and adjacent area seating combinations.

[0090] When there are insufficient preferred seats and users have a preference for alternative seats in adjacent areas at the same price, the ticketing platform searches for seat combinations in adjacent areas within the same price range. If the seat combinations in adjacent areas meet the requirements of the number of ticket buyers, sales restrictions, and rigid ticket purchase preferences, they are determined as the preferred alternative seat combinations or alternative seat combinations that can be displayed, based on the substitution acceptance ratio and substitution acceptance benchmark table.

[0091] When there are remaining tickets in the preferred area but not enough to meet the demand for consecutive seats in the same row, the ticketing platform first searches for consecutive seat combinations in the same row in other areas within the same price range. If a seat combination that meets the criteria exists, it is added to the priority alternative seat combination list. If no consecutive seat combination in the same row meets the criteria, the platform then searches for adjacent seat combinations in the rows before and after the user. If the acceptance rate of the adjacent seat combinations in the rows before and after the user reaches the priority alternative benchmark, it is added to the priority alternative seat combination list; if it reaches the displayable alternative benchmark but not the priority alternative benchmark, it is added to the displayable alternative seat combination list; if it does not reach the displayable alternative benchmark, an alternative seat combination requiring user confirmation is added only if no other seat combination meets the user's rigid ticketing preference.

[0092] When no available seat combinations are available for the preferred fare tier, the ticketing platform first searches for seat combinations in adjacent areas within the same fare tier, and then searches for different seating combinations within the same area. Seat combinations in adjacent fare tiers are only considered for alternative seat combination generation if the fare range is not written into rigid ticketing preferences, or if the user explicitly allows adjacent fare tiers to be substituted in this transaction.

[0093] When multiple alternative preferences exist in the user's performance viewing preference stratification results, the ticketing platform generates alternative seat combinations in the following order: priority alternative call range, displayable alternative call range, and alternative range requiring user confirmation. Alternative seat combinations belonging to the same call range are first arranged according to whether they meet the priority matching preference, and then arranged in the order of same ticket price, same region, adjacent regions, and adjacent ticket price tiers. If a seat combination belongs to multiple alternative seat options, the platform retains the identifier of the alternative option that deviates least from the rigid ticketing preference and records other related alternative options in the candidate seat combination record.

[0094] After completing the seat combination substitution interaction, the ticketing platform generates candidate seat combination records, which record the seat combination identifier, seat number set, combination type, recommendation level, substitution seat method type, substitution acceptance ratio, referenced substitution acceptance benchmark table version number, rigid ticket purchase preference verification result, and priority matching preference ranking basis.

[0095] Candidate agent combinations are recorded and written into the agent matching data pool, serving as the data basis for subsequent real-time transaction status verification and lock-up inventory feedback processing.

[0096] S4. Based on real-time transaction status data, the preferred seat combination and the tiered alternative seat combination are locked, pending payment, release countdown, sold, system reserved, and available for sale. When the preferred seat combination is unavailable, the locked seat inventory is switched according to the alternative tier, and a recommended seat set is generated.

[0097] Furthermore, the ticketing platform reads candidate seat combination records, real-time transaction status data, current ticket purchase request data, and user viewing preference stratification results from the seat matching data pool, verifies the transaction status of candidate seat combinations, and generates a set of recommended seats, a set of seats to be confirmed, and rematch records.

[0098] The candidate seating combination record includes the preferred seating combination, the preferred alternative seating combination, the alternative seating combinations that can be displayed, and the alternative seating combinations that require user confirmation. Real-time transaction status data includes seat availability status, seat sold status, seat locked status, seat pending payment status, payment failure release status, release countdown status, system reserved status, and unsaleable status. Current ticket purchase request data includes user ID, target performance project, showtime ID, number of ticket buyers, request time, ticket purchase request ID, and current page session ID.

[0099] The ticketing platform uses candidate seat combinations as the verification unit, rather than verifying individual seats independently. For each candidate seat combination, it reads the seat number, area number, row number, column number, fare tier, transaction status, order identifier, lock start time, lock end time, payment start time, payment end time, and status change source fields corresponding to all seats in the combination, and generates a seat combination transaction status verification record.

[0100] When all seats in a candidate seating combination are available for sale, and the combination still meets the rigid ticketing preferences in the user's viewing preference stratification results, the candidate seating combination is added to the recommended seating set. Rigid ticketing preferences include performance date, number of tickets purchased, price range, demand for consecutive seats, demand for adjacent seats, actively excluded areas, and ticketing conditions limited by platform transaction rules.

[0101] If a candidate agent combination contains agents that are already sold, unsellable, or reserved by the system, the combination will be removed from the current recommendation range, and the invalid agent number, status type, and change time will be written into the transaction status verification record; the combination will not be included in the recommended agent set or the agent set to be confirmed.

[0102] When there are seats in the candidate seat combination that are locked, pending payment, have a release countdown, or have been released after payment failure, the ticketing platform will make a judgment based on the order identifier, session identifier, lock deadline, payment deadline, and release processing result: if the seat belongs to the current user and is still within the validity period, it will be retained in the current order confirmation scope; if the seat belongs to another party or the release is incomplete, it will not be given priority; if the release is completed and the status changes to available for sale, it will be re-entered for transaction status verification.

[0103] When some seats in a candidate seat combination are available for sale, while others are sold, locked, or pending payment, resulting in a shortage of seats within the combination to meet the current number of ticket buyers, the candidate seat combination will not be split to form a new preferred seat combination. The ticketing platform will record the reason for the combination's failure in the candidate seat combination transaction status verification record and will call other candidate seat combinations under the same ticket purchase request for verification.

[0104] The lock-up inventory feedback interaction process takes candidate agent combination records and real-time transaction status verification results as input, and sequentially calls the preferred agent combination, the preferred alternative agent combination, the alternative agent combination that can be displayed, and the alternative agent combination that requires user confirmation.

[0105] When all preferred seat combinations pass transaction status verification, they are added to the recommended seat set. If any seat in the preferred seat combination cannot be added to the recommended seat set due to being sold, unsaleable, reserved by the system, locked by another party, pending payment by another party, or incomplete release, the ticketing platform will use the preferred alternative seat combination from the candidate seat combination record.

[0106] When invoking a preferred alternative seating combination, the ticketing platform first verifies whether the combination still satisfies the rigid ticketing preference in the user's performance preference stratification results, and then verifies the real-time transaction status of all seats within the combination. If the preferred alternative seating combination satisfies the rigid ticketing preference and all seats are available for sale, the combination is added to the recommended seating set, and the switching source from the preferred seating combination to the preferred alternative seating combination is recorded in the seating combination transaction status verification record.

[0107] It should be noted that when a preferred alternative seat combination cannot be included in the recommended seat set due to changes in real-time transaction status, the ticketing platform continues to use the displayable alternative seat combinations. If a displayable alternative seat combination meets rigid ticketing preferences and all seats are available for sale, it is added to the recommended seat set, retaining the alternative seat type, alternative acceptance ratio, referenced alternative acceptance benchmark table version number, and benchmark completion source fields. If a displayable alternative seat combination involves an alternative direction that requires user confirmation, the combination is marked as a display result requiring confirmation.

[0108] When the preferred seating combination, preferred alternative seating combination, and displayable alternative seating combination all fail transaction status verification, the ticketing platform will retrieve alternative seating combinations requiring user confirmation. Alternative seating combinations requiring user confirmation must not include areas actively excluded by the user, must not violate the ticketing conditions stipulated in the platform's transaction rules, and must not change the performance date or the number of tickets purchased. If the combination involves substitution of adjacent price tiers, substitution of non-consecutive seats in the same row, or other substitution directions related to rigid ticketing preferences, the platform will retain a confirmation flag and will not directly use it as the preferred recommendation result.

[0109] When all candidate seat combinations fail to form a recommended seat set, the ticketing platform generates a rematching record. The rematching record includes the user identifier, ticket request identifier, target performance project, showtime identifier, invalid seat combination identifier, invalid status type, invalid seat number, rematching trigger time, and retained rigid ticketing preference fields. During rematching, the ticketing platform returns to the seat resource matching stage and regenerates candidate seat combinations according to the original user viewing preference stratification results; the regenerated seat combinations must not deviate from the rigid ticketing preferences.

[0110] When the price range is already written into the rigid ticketing preference, and the preferred seat combination is locked or sold out, the ticketing platform will only call up the preferred alternative seat combination and the available alternative seat combinations within that price range. Seat combinations for adjacent price tiers will only be written as alternative seat combinations requiring user confirmation if the user explicitly allows substitution of adjacent price tiers in the current ticketing request.

[0111] When consecutive seat requests are already written into rigid ticketing preferences, and the preferred consecutive seat combination in the same row is locked or sold out, the ticketing platform will prioritize other consecutive seat combinations in the same row within the same price range. If no other consecutive seat combinations in the same row exist, adjacent seat combinations in the rows before and after will be used; if adjacent seat combinations in the rows before and after cannot pass transaction status verification, non-consecutive seat combinations in the same row will only be reserved as alternative seat combinations requiring user confirmation.

[0112] When a user has actively excluded a region that is already written into their rigid ticketing preferences, the seat lock inventory feedback interaction process will not invoke any seat combinations that include that region. This exclusion rule applies to preferred seat combinations, preferred alternative seat combinations, alternative seat combinations that can be displayed, and alternative seat combinations that require user confirmation.

[0113] When both the seating combination corresponding to the currently viewed area and the seating combination corresponding to the historically frequently selected area pass the transaction status verification, the ticketing platform determines the display arrangement according to the preference processing chain order in the user's viewing preference stratification results. If there is an "added to cart" record for the currently viewed area, the seating combination corresponding to this area will be displayed before the seating combination corresponding to the historically frequently selected area; if there is only a browsing or click record for the currently viewed area, the seating combination corresponding to the historically frequently selected area will be displayed before the seating combination corresponding to this area.

[0114] When the status of the same seat combination changes during the transaction status verification process, the ticketing platform retains verification records before and after the status change. The verification records include the verification time, transaction status before verification, transaction status after verification, source of status change, corresponding order identifier, corresponding seat number, and seat combination identifier. For seat combinations that are locked, released, and made available for sale multiple times within a short period, the ticketing platform uses the most recently written real-time transaction status as the current verification basis.

[0115] After completing real-time transaction status verification and seat lock-up inventory feedback processing, the ticketing platform generates a record of recommended seat sets. This record includes the user identifier, target performance, showtime identifier, ticket purchase request identifier, recommended seat combination identifier, seat number set, combination type, region number, row number range, column number range, ticket price tier, recommendation level, transaction status verification result, seat lock-up verification result, alternative seat type, confirmation required identifier, switching source, referenced candidate seat combination record, and referenced user viewing preference stratification result record.

[0116] Recommended agent set records can be written into the agent matching data pool and used as the data basis for agent display, order submission and payment confirmation.

[0117] S5. Display recommended seat sets, collect user feedback on seat combinations (clicks, exclusions, add-to-cart, confirmation of alternatives, order submissions, payments, and refunds), write the feedback back to the seat matching data pool, and update user viewing preference stratification results, preference stratification benchmark table, and alternative acceptance benchmark table.

[0118] Furthermore, the ticketing platform reads recommended seat sets, current ticket purchase requests, user viewing preference stratification results, candidate seat combinations, and real-time transaction status data from the seat matching data pool to generate a seat matching display record corresponding to the current ticket purchase request. This seat matching display record records the seat combinations shown to the user, their display order, display level, transaction status verification results, and alternative seat types.

[0119] The recommended seat set records include preferred seat combinations, preferred alternative seat combinations, displayable alternative seat combinations, and alternative seat combinations requiring user confirmation. The ticketing platform generates a display queue according to the recommendation level, transaction status verification result, confirmation requirement identifier, and preference processing chain. Preferred seat combinations are arranged before preferred alternative seat combinations, which are arranged before displayable alternative seat combinations, and displayable alternative seat combinations are arranged before alternative seat combinations requiring user confirmation. Seat combinations whose transaction status verification result indicates they can directly proceed to the order submission process are arranged before seat combinations awaiting confirmation.

[0120] The seat matching display record includes user ID, ticket purchase request ID, session ID, displayed seat combination ID, seat number set, ticket price tier, recommendation level, whether it belongs to an alternative seat combination, type of alternative seat method, confirmation required, switching source, and the referenced set of recommended seats. When the displayed object is the preferred seat combination, it records the rigid ticket purchase preference and priority matching preference it satisfies; when the displayed object is an alternative seat combination, it records the alternative source and confirmation required.

[0121] User actions on the seating display page are recorded in the user action feedback log. This log is the raw feedback record of user actions within a single page session, used to record the user's immediate actions on the displayed seating combinations. It is not directly equivalent to order result records or seating matching closed-loop records. The user action feedback log includes user identifier, ticket request identifier, target performance project, showtime identifier, displayed seating combination identifier, action time, action type, page session identifier, and action source. Action types include clicking on a seating combination, expanding seating details, skipping seating combinations, excluding seating areas, adding to cart, canceling adding to cart, confirming alternative seating, rejecting alternative seating, submitting an order, canceling an order, payment successful, payment failed, payment timeout, and refund completed.

[0122] The seat matching display records, user operation feedback records, order submission records, payment result records, and refund records generated within the same ticket purchase request are linked and summarized upon the end of the page session, completion of order payment, order cancellation, payment timeout, or completion of refund, forming a closed-loop seat matching record. This closed-loop record represents the complete processing chain of a single seat matching process, from recommendation display, user operation, order submission, payment result to refund result. Its content includes user identifier, ticket purchase request identifier, target performance project, showtime identifier, displayed seat combination record, user operation feedback record, order submission record, payment result record, refund record, user viewing preference stratification results before and after the update, the referenced benchmark table version number, and data write time.

[0123] User operation feedback records are used for display queue adjustments and user behavior tracking within the current ticket purchase request; seat matching closed-loop records are used for subsequent updates to user viewing preference stratification results, preference confirmation ratio, substitution acceptance ratio, preference stratification benchmark table, and substitution acceptance benchmark table. Payment success records, payment failure records, payment timeout records, order cancellation records, and ticket refund completion records are written to the seat matching closed-loop record in the form of an order result field, and do not directly replace order results with a single click, view, or add-to-cart action.

[0124] When a user clicks on a displayed seating combination, the ticketing platform records the click status in the user's action feedback log and associates the clicked seating combination with the corresponding display record. The click record is not directly written to the user's historical successful orders, nor does it directly update the preference hierarchy benchmark table or the alternative acceptance benchmark table. The click record is used for display queue adjustments within the current ticket purchase request and is retained in the user's performance behavior data after the current page session ends.

[0125] When a user adds a display seat combination to their shopping cart, the ticketing platform records the add-to-cart status, add-to-cart time, seat combination identifier, seat number set, and corresponding recommendation level. If the added seat combination is a preferred combination, the corresponding region number, ticket price tier, and combination type are written to the current requesting side's priority matching preference record; if the added seat combination is an alternative combination, the alternative seat method type is written to the current requesting side's alternative behavior record. Records of adding seats to the cart but not submitting an order are not considered successful payment records and are not included in the payment completion statistics for preference confirmation ratio and alternative acceptance ratio.

[0126] When a user cancels an item from their shopping cart, the ticketing platform records the cancellation time, the seat combination identifier, and the source of the cancellation. If a user cancels an item and then selects a different seat combination within the same page session, the ticketing platform associates the cancellation record with the reselection record as a seat combination switch record in the current purchase request. This seat combination switch record is used to adjust the display order within the current request and does not directly change the preference hierarchy benchmark table or the alternative acceptance benchmark table.

[0127] When a user confirms a replacement seat combination, the ticketing platform records the confirmation operation, the replacement seat type, confirmation details, and confirmation time. The confirmed replacement seat combination still needs real-time transaction status verification before order submission. If the verification result shows the seat is still available and does not violate rigid ticketing preferences, the order submission process is allowed; if the verification result changes, the ticketing platform can call the next recommended seat combination in the set or generate a new matching record.

[0128] When a user refuses a proposed alternative seating arrangement, the ticketing platform records the refusal action, the type of alternative seating arrangement, and the time of refusal. The refused alternative seating arrangement is displayed in a lower order within the current ticket purchase request; when candidate seating arrangements are generated again within the same page session, the refused alternative seating arrangement is not considered a priority option. The refusal record is stored in the user's viewing behavior data but is not included in the number of payment completions for the alternative acceptance rate.

[0129] When a user submits an order, the ticketing platform reads the submitted seat combination identifier, seat number set, number of passengers, price tier, recommendation level, and alternative seat type, generating an order submission record. Before order submission, real-time transaction status data is read again to verify the transaction status of the seat combination. If the transaction status verification passes, the process of locking seats and payment begins; if the transaction status verification fails, the order submission record is written with a submission failure status, and the seat lock inventory feedback interaction is invoked to generate a new set of recommended seats.

[0130] When a user completes payment, the ticketing platform generates a payment success record and writes it into historical payment result data and user viewing behavior data. The payment success record includes user identifier, order identifier, target performance project, showtime identifier, seat number set, region number, row number range, column number range, ticket price tier, number of tickets purchased, seat combination type, recommendation level, whether it belongs to an alternative seat combination, alternative seat method type, payment completion time, and referenced seat matching display record.

[0131] Successful payment records are used to update user personal preference statistics. If a successfully paid seat combination falls under the order type corresponding to fare range preference, consecutive seat preference, frequently selected area preference, multi-person travel preference, same fare area preference, or adjacent area preference, the ticketing platform adds the order to the user's valid historical successful order set for subsequent recalculation of preference confirmation ratios. If a successfully paid seat combination is an alternative seat combination, the ticketing platform adds the order to the user's alternative acceptance record for subsequent recalculation of the alternative acceptance ratio for the corresponding alternative seat method.

[0132] When a user's payment fails, times out, or an order is cancelled, the ticketing platform generates a payment incomplete record and writes it into the historical payment result data. The payment incomplete record includes the order identifier, seat combination identifier, seat number set, payment failure time, payment failure type, release processing status, and the time of re-entry into the available sales area. Payment incomplete records are not included in the user's valid historical successful order set, nor are they counted in the number of completed payments in the alternative acceptance ratio. Seats that have completed release processing after payment incompleteness will re-enter the seat resource matching and transaction status verification process according to real-time transaction status data.

[0133] It should be noted that when a user completes a ticket refund, the ticketing platform generates a refund completion record and links it to the original successfully paid order. The refund completion record includes the original order identifier, refund time, set of refund seat numbers, refund reason type, and refund processing status. This record is retained in the user's performance viewing behavior data; however, when calculating the preference confirmation ratio later, orders that have already been refunded are not considered valid historical successful orders in the ratio calculation, thus avoiding the inclusion of cancelled ticket purchases in preference stratification processing.

[0134] Historical recommendation display data is updated based on the actual front-end display results of the displayed seat combinations. When an alternative seat combination is written to the display page and a display record is generated, the ticketing platform writes the number of times that alternative seat combination is displayed into the historical recommendation display data. After an alternative seat combination is displayed, if a user completes payment, the number of payment completions for the corresponding alternative seat combination is written into the historical payment result data. If an alternative seat combination is only displayed but not clicked, clicked but not added to cart, added to cart but not submitted, or submitted but not paid for, only the display behavior and intermediate operation behavior are recorded, not as payment completion.

[0135] The ticketing platform updates the user viewing preference stratification results record based on user operation feedback records. Within the current ticket purchase request, when a user clicks, adds to the cart, or confirms seat combinations within the same price tier multiple times, that price tier is written into the current request's priority matching preference; when a user skips or excludes the same seat area multiple times, that seat area is written into the exclusion record or downgraded in the current ticket purchase request; when a user confirms an alternative seat option and enters the order submission process, that alternative seat option is written into the current request's alternative behavior record; when a user rejects an alternative seat option, that alternative seat option is written into the current request's alternative rejection record.

[0136] The updating of user viewing preference stratification results is divided into current request updates and historical statistics updates. Current request updates are based on clicks, add-to-cart, skip, exclude, confirm alternatives, and reject alternatives behaviors in the page session, without changing the preference stratification baseline table. Historical statistics updates are based on successful payment records, incomplete payment records, and completed refund records, and are used to recalculate the user preference confirmation ratio and alternative acceptance ratio in subsequent transactions.

[0137] The preference stratification benchmark table and the alternative acceptance benchmark table are updated according to the complete ticketing cycle. For target performances currently on sale, records in the locked, pending payment, release countdown, and incomplete payment states are not included in the proportion distribution statistics of the preference stratification benchmark table and the alternative acceptance benchmark table. Records with successful payment, failed payment and completed release, order cancellation completed, and ticket refund completed are written to the seat matching data pool according to their status type. For performances that have completed their full ticketing cycle, the ticketing platform regenerates the proportion distribution of the corresponding groups based on successful payment orders, recommended display records, and payment result records, and updates the preference stratification benchmark table and the alternative acceptance benchmark table accordingly.

[0138] When updating the preference stratification benchmark table, the ticketing platform regroups users according to performance category, venue type, ticket price range, number of tickets purchased, and user purchase scenario. It then recalculates the proportion distribution of each performance preference type in the valid historical successful orders of sample users and re-records the median, upper quartile, priority matching benchmark, and rigid confirmation benchmark. Similarly, when updating the alternative acceptance benchmark table, the ticketing platform regroups users according to performance category, venue type, ticket price range, number of tickets purchased, and alternative seating method. It then recalculates the alternative acceptance proportion distribution for each alternative seating method and re-records the median, upper quartile, displayable alternative benchmark, and priority alternative benchmark.

[0139] Each time the preference stratification benchmark table and the alternative acceptance benchmark table are updated, the ticketing platform retains the version number before the update, the version number after the update, the update date, the applicable performance group, the number of sample users, the number of valid orders, the number of recommended displays, the number of payment completions, and the source of the benchmark completion. Ticket purchase requests that are being processed continue to use the benchmark table version referenced at the beginning of the request; newly initiated ticket purchase requests use the updated benchmark table version.

[0140] After completing the display of seat matching results and the writing back of user operation feedback, the ticketing platform generates a closed-loop record for seat matching. This record includes the user identifier, ticket purchase request identifier, target performance project, showtime identifier, displayed seat combination record, user operation feedback record, order submission record, payment result record, refund record, updated user viewing preference stratification result record, the version number of the baseline table before and after the update, and the data write time. The closed-loop record is written to the seat matching data pool for subsequent preference stratification, seat combination generation, transaction status verification, and display queue generation in ticket purchase requests.

[0141] In this embodiment, historical ticket purchase requests for similar performances within the same ticketing platform are selected as test subjects, and the method of this invention is compared with the conventional static ticket price / region recommendation method. The conventional static ticket price / region recommendation method refers to the ticketing platform directly generating recommended seats from the available seats according to the price range, seat area, and current availability of seats selected by the user, without establishing a preference hierarchy benchmark table or an alternative acceptance benchmark table, without distinguishing between rigid ticket purchase preferences, priority matching preferences, and alternative preferences, and without performing seat lock-up inventory feedback switching according to the alternative hierarchy when the preferred seat becomes unavailable.

[0142] The seat matching success rate refers to the percentage of user requests that initiate the order submission process based on the recommended seat combination initially provided by the platform during a single seat recommendation process. This percentage is calculated as follows: the number of requests that meet the user's needs for the number of passengers, price range, consecutive seats, actively excluded areas, and real-time availability. The recommendation acceptance rate refers to the percentage of user requests that add the displayed seat combination to their cart, confirm the substitution, or submit an order, within the corresponding ticket purchase request type. Records of users merely browsing without adding to cart, confirming substitution, or submitting an order are not included in the recommendation acceptance rate.

[0143] In this embodiment, as Figure 5 The image shows a comparison of seat matching success rates under different remaining ticket percentage groups. Figure 5 As can be seen, with the increase in the proportion of remaining tickets, the success rate of seat matching in the first instance of the proposed method and the conventional static ticket price / region recommendation method both show an upward trend. However, the proposed method maintains a higher success rate in the first instance of seat matching within each group of remaining tickets, especially in the low remaining ticket range where the difference is more pronounced. This indicates that by clarifying rigid ticketing preferences through hierarchical user preference interaction processing, generating hierarchical alternative seat combinations through seat combination substitution interaction processing, and switching between locked, pending payment, and release countdown states through locked seat inventory feedback interaction processing, the initially output seat combinations can more stably meet the user's core ticketing conditions and real-time transaction conditions, thereby improving the effectiveness of recommending seat combinations into the order submission process.

[0144] In this embodiment, as Figure 6 The image shows a comparison of recommendation acceptance rates for different types of ticket purchase requests. Figure 6 As can be seen, the method of this invention has a higher overall acceptance rate than conventional static price / region recommendation methods under various request types, including single-person ticket purchase, consecutive double seats, multi-person travel, same-price substitution, and adjacent price tier substitution. The difference is more pronounced under multi-person travel and alternative seat requests. This indicates that the method of this invention divides ticket purchase demand into rigid ticket purchase preferences, priority matching preferences, and substitutable preferences through a preference processing chain, and determines the calling level of alternative seat combinations by combining an alternative acceptance benchmark table. This allows it to continue generating seat combinations according to user-acceptable alternative directions even when preferred seats are insufficient, locked, or pending payment, thereby improving user acceptance of recommendation results and the stability of subsequent transaction processing in complex ticket purchase scenarios.

[0145] This embodiment also provides a computer device applicable to the seat intelligent matching method based on audience preferences, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the seat intelligent matching method based on audience preferences as proposed in the above embodiment.

[0146] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0147] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the seat intelligent matching method based on audience preferences as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0148] In summary, this invention, through user preference-based hierarchical interactive processing, merges the current explicit operation, preference confirmation ratio, and preference hierarchical benchmark table into rigid ticketing preferences, priority matching preferences, and alternative preferences, thereby clarifying the processing order of seat matching and achieving the beneficial effect of hierarchical identification of performance needs. Through seat lock inventory feedback interactive processing, it undertakes the transaction status verification of preferred seat combinations and hierarchical alternative seat combinations, ensuring that the recommended results can enter the order placement process when changes occur in lock, pending payment, or release status, achieving the beneficial effect of linkage and matching between seat substitution and transaction status.

[0149] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A seat matching method based on audience preferences, characterized in that, include: Acquire user viewing behavior data, current ticket purchase request data, performance ticketing resource data, real-time transaction status data, historical recommendation display data, and historical payment result data to form a seat matching data pool. Based on historical successful orders, historical recommendation display data, and historical payment result data, generate a preference stratification benchmark table and an alternative acceptance benchmark table containing median benchmark and upper quartile benchmark. Based on the seat matching data pool and the preference hierarchy benchmark table, the preference confirmation ratio of various user viewing preferences is output. Combined with the explicit operation records in the current ticket purchase request, the viewing preferences are divided into rigid ticket purchase preferences, priority matching preferences and alternative preferences, forming a preference processing chain. Based on the preference processing chain and performance ticketing resource data, matching is performed on a per-seat combination basis. First, seat combinations are filtered out according to rigid ticket purchase preferences, and then seat combinations are arranged according to priority matching preferences. When the preferred seat combinations are insufficient, a hierarchical alternative seat combination is generated by combining the alternative acceptance benchmark table. Based on real-time transaction status data, the preferred seat combination and the tiered alternative seat combination are locked, pending payment, release countdown, sold, system reserved and available status verified. When the preferred seat combination is unavailable, the locked seat inventory is switched according to the alternative tier to generate a set of recommended seats. The system displays recommended seating arrangements and collects user feedback on seat combinations, including clicks, exclusions, add-to-cart actions, confirmation of alternatives, order submissions, payments, and refunds. This feedback is then written back to the seat matching data pool to update user viewing preference stratification results, preference stratification benchmark tables, and alternative acceptance benchmark tables.

2. The seat matching method based on audience preferences as described in claim 1, characterized in that, The generation of the preference stratification benchmark table and the alternative acceptance benchmark table, which include the median benchmark and the upper quartile benchmark, includes: Based on successful payment orders within the complete historical ticketing period, the orders are grouped according to performance category, venue type, ticket price range, number of tickets purchased range, and user purchase scenario. The distribution of the occurrence ratio of various performance preferences in the valid historical successful orders of the sample users is statistically analyzed. The median of the occurrence ratio distribution is recorded as the priority matching benchmark, and the upper quartile of the occurrence ratio distribution is recorded as the rigid confirmation benchmark, generating a preference stratification benchmark table. Based on historical recommendation display data and historical payment result data, the data is grouped according to performance category, venue type, ticket price range, number of tickets purchased range, and alternative seating method. The distribution of the alternative acceptance rate of each type of alternative seating method among the sample users is statistically analyzed. The median of the alternative acceptance rate distribution is recorded as the displayable alternative benchmark, and the upper quartile of the alternative acceptance rate distribution is recorded as the preferred alternative benchmark, thus generating an alternative acceptance benchmark table.

3. The intelligent seat matching method based on audience preferences as described in claim 1, characterized in that, The preference confirmation ratios for various viewing preferences of the output users include: Filter valid historical successful orders from the seat matching data pool that have complete user identifier, performance identifier, showtime identifier, ticket price range, seat area, number of tickets purchased, seat combination type, and payment success status; For each of the following preferences—ticket price range, consecutive seating, frequently selected area, group travel, same ticket price area, and adjacent area—the number of orders that meet the corresponding viewing preferences from the user's valid historical successful orders is counted. The ratio between the corresponding order number and the total number of the user's valid historical successful orders is used as the preference confirmation ratio for that type of viewing preference.

4. The intelligent seat matching method based on audience preferences as described in claim 1 or 2, characterized in that, The process of dividing performance viewing preferences into rigid ticket-buying preferences, priority matching preferences, and substitutable preferences, forming a preference processing chain, includes: When the number of valid historical successful orders of a user reaches the minimum statistical sample size in the preference stratification benchmark table, the preference confirmation ratio of the performance viewing preference is not lower than the corresponding rigid confirmation benchmark, and there is a clear operation record in the current ticket purchase request that is consistent with the performance viewing preference, the performance viewing preference will be written into the rigid ticket purchase preference. When the number of valid historical successful orders of a user reaches the minimum statistical sample size in the preference stratification benchmark table, and the preference confirmation ratio of the performance viewing preference is not lower than the corresponding priority matching benchmark, but the performance viewing preference is not explicitly restricted in the current ticket purchase request, the performance viewing preference will be written into the priority matching preference. When the number of valid historical successful orders of a user does not reach the minimum statistical sample size, a rigid ticket purchase preference is generated based on the explicit operation record in the current ticket purchase request, and a priority matching preference is generated based on browsing, dwelling, clicking, favorite or adding to cart behavior. A preference processing chain is formed in the order of rigid ticket purchase preference, priority matching preference and alternative preference.

5. The seat matching method based on viewing preferences as described in claim 4, characterized in that, The matching based on the preference processing chain and performance ticketing resource data, performed on a per-seat combination basis, includes: When there is only one person purchasing a ticket, the single seat will be used as a seat group. When the number of ticket purchasers is greater than one, the system generates consecutive seat combinations in the same row, spaced seat combinations in the same row, adjacent seat combinations in front and behind rows, and seat combinations in adjacent areas based on seat number, area number, row number, column number, ticket price level, and seat combination status. Based on rigid ticket purchasing preferences, seat combinations are screened to remove those that do not meet the conditions of performance number, number of ticket buyers, price range, consecutive seat demand, adjacent seat demand, actively excluded areas, and platform transaction rules. The selected agent combinations are arranged according to priority matching preferences.

6. The seat matching method based on viewing preferences as described in claim 5, characterized in that, When the preferred agent combination is insufficient, generating a tiered alternative agent combination based on the alternative acceptance benchmark table includes: Based on users' historical recommendation display records and historical payment results data, the number of times users displayed the alternative seating options for adjacent areas with the same ticket price, different rows with the same area, adjacent seats in front and behind, non-consecutive seats in the same row, and adjacent ticket price levels, as well as the number of times payment was completed after the display, were counted. The acceptance rate of the corresponding alternative seating option was determined based on the ratio between the number of times payment was completed after the display and the number of times the option was displayed. When the replacement acceptance rate of the alternative seat method is not lower than the priority replacement benchmark in the replacement acceptance benchmark table, a priority alternative seat combination is generated according to the alternative seat method. When the replacement acceptance rate of the alternative seat method is not lower than the displayable alternative benchmark in the alternative acceptance benchmark table and is lower than the priority alternative benchmark, a displayable alternative seat combination is generated according to the alternative seat method. When the acceptance rate of alternative seating arrangements is lower than the baseline for displaying alternatives, or when the number of times the user displays the corresponding alternative seating arrangement does not reach the minimum statistical sample size, the seating arrangement generated by the alternative seating arrangement will be used as the alternative seating arrangement that requires user confirmation.

7. The intelligent seat matching method based on audience preferences as described in claim 6, characterized in that, The step of switching the locked seat inventory feedback according to the substitution level to generate a set of recommended agents includes: Using the preferred seat combination and the tiered alternative seat combination as the verification unit, read the available status, sold status, locked status, pending payment status, release countdown status, system reserved status, and unsaleable status of all seats in each seat combination; When all seats in the preferred seating combination are available for sale and meet the rigid ticket purchase preference, the preferred seating combination will be added to the recommended seating set. If any of the preferred agent combinations contain agents that are sold, unsellable, reserved by the system, locked by the other party, pending payment by the other party, or whose release is incomplete, the preferred alternative agent combination shall be invoked for verification. When the preferred alternative agent combination fails the real-time transaction status verification, the alternative agent combination that can be displayed will continue to be called. If the alternative agent combination that can be displayed still cannot pass the real-time transaction status verification, read the alternative agent combination that requires user confirmation. When none of the seat combinations can satisfy the rigid ticketing preference, a rematch record is generated, and candidate seat combinations are regenerated according to the original user viewing preference stratification results.

8. The intelligent seat matching method based on viewing preferences as described in claim 2 or 7, characterized in that, The step of writing the feedback back to the seat matching data pool and updating the user viewing preference stratification results, preference stratification benchmark table, and alternative acceptance benchmark table includes: Write the user's actions regarding the displayed seat combinations, such as clicking, excluding, adding to cart, confirming alternatives, rejecting alternatives, submitting orders, successful payment, failed payment, payment timeout, order cancellation, and ticket refund completion, into the user operation feedback record; The successfully paid seat combination is added to the user's valid historical successful order set, and the preference confirmation ratio of the user's various viewing preferences is updated; Write the alternative seat combination that was displayed and payment was completed into the user's alternative acceptance record, and update the user's alternative acceptance ratio for the corresponding alternative seat method; After the complete ticketing period ends, based on newly paid successful orders, historical recommendation display records, and historical payment result data, the distribution of preference occurrence ratio and the distribution of alternative acceptance ratio are recalculated, and the priority matching benchmark and rigid confirmation benchmark in the preference stratification benchmark table, as well as the displayable alternative benchmark and priority alternative benchmark in the alternative acceptance benchmark table, are updated.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the seat intelligent matching method based on audience preferences as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the seat intelligent matching method based on audience preferences as described in any one of claims 1 to 8.

Images