Transaction Filtering
How to control which parts of a transaction count toward commissions: line items, discounts, fees, shipping, taxes, and product-level filters.
Last updated: April 10, 2026
When a customer places an order, the resulting transaction contains several types of financial data: the products purchased, any discounts applied, fees, shipping costs, and taxes. By default, Siren does not include any of this data in the commission calculation. You choose which parts count by enabling transaction compilers on your programs and distributors.
Transaction compilers are the building blocks that tell Siren how to read a transaction. Each compiler handles one type of data, and you can enable as many as you need for a given program or distributor.
Transaction compilers
There are five built-in compilers. Each one adds a specific piece of the transaction to the commission calculation.
Line Items
Includes the actual products purchased. This is the most common compiler and the foundation of most commission calculations. When a customer buys three products, the line items compiler pulls in each product’s price so the incentive structure can calculate the reward.
When line items are enabled, additional filtering options appear. These let you narrow which products count toward the commission. See the line item filters section below for details.
Discounts
Includes discount amounts in the calculation. When enabled, Siren subtracts any applied coupons or discounts from the total before calculating the commission. If a $120 product has a $20 coupon applied, the commission is calculated on $100. If discounts are not enabled, the commission would be calculated on the pre-discount amount.
This is almost always something you want enabled. Paying commission on revenue you didn’t actually collect is rarely the intent.
Fees
Includes fees like WooCommerce signup fees or subscription setup fees. Whether to enable this depends on your situation. If you charge a one-time setup fee on top of a subscription, you may want that fee included in the commission base. If the fee is a pass-through cost that doesn’t represent real revenue, you probably don’t.
Shipping
Includes shipping costs in the commission calculation. This is rarely enabled. Shipping is typically a pass-through cost, and most businesses don’t want to pay commission on it.
Taxes
Includes tax amounts in the commission calculation. Like shipping, this is almost never enabled. You don’t want to pay a percentage commission on the tax you owe the government.
Line item filters
When the Line Items compiler is enabled, four additional filters appear. These narrow which products in the transaction are eligible for the commission. If no filters are set, all line items are included.
Category filter
Restricts commissions to products in specific product categories. You provide a list of category IDs, and only items that belong to those categories are included.
A course platform might use this to pay commissions only on products in the “courses” category. Physical merchandise, free downloads, and other product types in the same store would be excluded even if they appear in the same order.
SKU filter
Restricts commissions to products matching specific SKUs. You provide a list of SKUs, and only items with a matching SKU are included.
This is useful for fine-grained control. If you’re running a promotion where affiliates only earn on a handful of premium products, list those SKUs and everything else is automatically excluded.
Product type filter
Restricts commissions based on whether an item is a one-time product or a subscription. You can choose to include products, subscriptions, or both.
A common use is separating subscription commissions from one-time purchase commissions. One program pays a percentage on subscription sign-ups. A different program pays a flat fee per one-time product. The product type filter makes that separation possible without duplicating your product catalog.
Collaborator owned filter
Restricts commissions to products that the collaborator created or owns. A line item only counts if the collaborator tied to the conversion is listed as an owner of that product.
This is designed for royalty programs. On a marketplace where multiple creators sell their own products, this filter ensures each creator only earns royalties on their own work. A creator who wrote Course A earns when Course A sells, but not when Course B sells, even if both appear in the same order.
How filters combine
When you enable more than one filter, they work together as a combined requirement. A line item must pass every active filter to be included. If any single filter excludes it, the item is excluded.
For example, setting a category filter for “courses” and enabling the collaborator owned filter means a product must be in the “courses” category AND be owned by the collaborator. A course owned by someone else is excluded. A non-course product owned by the collaborator is also excluded.
This AND behavior means adding more filters always narrows the set of eligible products. If nothing is matching, check whether your filters are too restrictive in combination.
Where filtering is configured
Transaction compilers and line item filters are configured in two places.
On a program, compilers control which parts of the transaction count when a conversion happens. If a customer buys three items but only one passes the line item filters, the commission is calculated against that one item alone.
On a distributor, compilers control which transactions and line items contribute to the distribution’s reward pool over the tracking period.
The same compilers and filters are available in both contexts.
For developers: Transaction compilers are an extension point. See the transaction compilers extension guide for how to build your own compiler or filter.