Skip to main content

Chapter 21 — Pricing Rules: One Big Filter

Attend onboarding guide · ~8 min read · ↑ Back to contents

Chapter 8 explained how a price is made: price code × ticket type code = an exact amount. This chapter answers the question that's been hanging ever since: with all those combinations sitting in the database, how does the system decide which price a particular fan actually gets?

The answer is smaller than you'd expect.

Start with everything, then filter​

When inventory is built (Chapter 17), Attend pulls all the pricing the vendor has — every price code × ticket type code combination, for every event. That's the unfiltered source. A fan should never see all of it: the same physical ticket might exist at full price, at a game-pack discount, and — in the Pass product — at $0.

A pricing rule is just the system's way of saying which slice of that pricing a given person can see. That's the whole concept:

Pricing = filtering. Get the seats, join them with all the prices, then filter by the rule the fan qualifies for. One extra AND in the SQL.

The rule itself​

A rule belongs to a program (so a Black Friday program gets its own rules) and is mostly a name plus a few switches. In tbl_pricing_rules each row names a rule (e.g. Pricing for SEAT_LEVEL_PROGRAM_1), marks it published, gives it a priority, and sets its pricingMode (event_level or suite_level):

  • Live only when published and active — a rule is evaluated at runtime only when its status is published and isActive is true (and isActive defaults to false). A published-but- inactive rule simply never fires, which is a common "why isn't my pricing showing?" gotcha.
  • Priority — a fan qualifies for exactly one rule at a time. If several rules' conditions match, priority decides which one wins.
  • Show all pricing (showAllAvailable) — a rare escape hatch: no filtering at all, used when the team only hands Attend the pricing it wants sold in the first place.
  • Conditions (what makes a fan eligible for a rule) can be: their account group (Chapter 14), the package they picked, the game pack they picked, or the number of events they selected. This is how "buy 7 games, get cheaper seats" actually happens — selecting 7 games qualifies you for a different rule.

What a rule contains: allowed combinations​

The rule's substance lives in a prices table: for this rule, these (event, price code, ticket type code) combinations are allowed — event by event, price code by price code, exactly one ticket type code each. Everything else is filtered out.

The ideal shape: for one rule, a seat has exactly one price — one price code → one ticket type code. The failure mode is when one rule maps the same price code (say P1) to both T1 and T2: a seat suddenly has two prices under the same rule. Different price codes (P1, P2) within one suite are fine.

  • ✅ One suite holding seats with different price codes (20 seats on P1, 10 on P2) — fine; each seat still has one price, and the suite price is just the sum of its seats.
  • ⚠️ The same price code mapped to two ticket type codes in one rule — now a seat has two prices. Vendors' systems can contain this; Attend has to draw the line. (Supporting multiple ticket type codes per seat properly is a planned feature — it exists in V2 and will be one of this team's projects.)

Suite-level rules: one more column​

For Premium, event-level filtering isn't always enough. Real case: suites 338 and 353 both sit on price code C, but the team wants ticket type /75 used for one and _76 for the other. Same event, same price code — different ticket type per suite.

So the suite-level prices table adds one column: suiteId — the same shape as the event-level table (rule, event, price code, ticket type), plus suiteId to distinguish rows. It's "just an extra AND in your SQL."

The rule's pricingMode decides which table is in play: event_level, suite_level, or suite_tier_level (tier-based suite pricing). Despite an earlier belief that the tier level was "never integrated," its tier tables are wired into getInventory, and the pricing reference documents all three — so don't ignore them. (A separate, more elaborate "buckets of rules" idea does have unused tables in the schema.)

Where it runs​

getInventory — the main API of the Flex product — is where all of this lands:

  1. Get the active program.
  2. Work out which rule this fan qualifies for (conditions + priority).
  3. Fetch the seats (or suites), join them with all the pricing.
  4. Filter by the rule ID. Done.

Example: the Warriors program has three rules — "Season default" (priority 3), "5+ game pack" (priority 2, condition: ≥5 events selected), and "Insider presale" (priority 1, condition: account group INSIDER). A fan in the insider group who picked 6 games matches all three — priority says the presale rule wins, and the seat map renders with only that rule's price combinations.

Recap​

  • Attend holds all vendor pricing; a pricing rule filters what a given fan sees. That's the entire pricing system: seats ⋈ prices, filtered by rule ID.
  • A fan qualifies for one rule at a time; conditions (account group, pack, package, event count) decide eligibility and priority breaks ties.
  • Ideal: one price per seat per rule. Multiple price codes in a suite = fine (suite price = sum of seats); one price code → two ticket type codes = the case to avoid (proper support is roadmap).
  • Suite-level rules add a suiteId column so two suites on the same price code can sell under different ticket type codes.

Next → Chapter 22 — The Cart That Mirrors the Vendor

Quick reference: the full column/table lookup for everything in this chapter is in Pricing Rules — Reference.