Meta Ads Ecommerce Conversion Metrics: Purchases, Value, Cost and ROAS

Meta Ads reports ecommerce activity across product views, carts, checkouts and purchases. However, the same stage may have several metrics in Ads Manager and several action_type values in the Marketing API.

For example, Purchases and Website Purchases are not always interchangeable. Purchases may combine several conversion locations, while Website Purchases are limited to events attributed to the website.

This guide explains how the main ecommerce conversion metrics work, where to find them in the API, how to calculate derived rates and which reporting limits affect the result.

Understanding Meta Ads Ecommerce Conversion Metrics

An ecommerce event is an action sent to Meta. An attributed conversion is an event that Meta associates with an ad interaction under the selected attribution setting.

These are not the same thing.

An online store may send 1,000 Purchase events to Meta during a week. Ads Manager will report only the purchases attributed to ads included in the report. The result depends on:

• The selected campaigns, ad sets or ads
• The reporting period
• The attribution setting
• The event source
• The conversion location
• Event matching
• Browser and server tracking
• Deduplication
• Privacy-related restrictions and modeling

Meta ecommerce metrics fall into three groups.

Count metrics

Count metrics show how many attributed actions occurred:

• Content Views
• Adds to Cart
• Checkouts Initiated
• Adds of Payment Info
• Purchases
• Website Purchases

Value metrics

Value metrics show the monetary value attached to attributed events:

• Purchases Conversion Value
• Website Purchases Conversion Value
• Average Purchases Conversion Value

Efficiency metrics

Efficiency metrics compare results with advertising spend or another funnel stage:

• Cost per Purchase
• Purchase ROAS
• Website Purchase ROAS
• Cart-to-Purchase Rate
• Checkout-to-Purchase Rate
• Average Order Value

Some efficiency metrics are available directly in Ads Manager or the Insights API. Others must be calculated from count and value metrics.

Meta Ads results may differ from web analytics or CRM data because the systems answer different questions. A CRM records completed orders. Meta reports orders that it attributes to advertising under its reporting rules.

How Meta Reports Ecommerce Conversions

Ads Manager presents ecommerce metrics as separate columns. The Marketing API usually returns them inside arrays.

The main Insights API fields are:

• actions
• action_values
• cost_per_action_type
• average_purchases_conversion_value
• purchase_roas
• website_purchase_roas

The current Meta Business SDK AdsInsights class defines these as valid Insights fields.

The actions field

The actions field returns a list of action records. Each record normally contains an action_type and a value.

A simplified response may look like this:

{
  "actions": [
    {
      "action_type": "omni_add_to_cart",
      "value": "180"
    },
    {
      "action_type": "offsite_conversion.fb_pixel_add_to_cart",
      "value": "165"
    },
    {
      "action_type": "omni_purchase",
      "value": "42"
    },
    {
      "action_type": "offsite_conversion.fb_pixel_purchase",
      "value": "39"
    }
  ]
}

The API does not return one top-level field for every standard ecommerce event. The integration must find the required action_type inside the array.

The action_values field

The action_values field follows the same structure but contains monetary values associated with actions.

For example:

{
  "action_values": [
    {
      "action_type": "omni_purchase",
      "value": "5240.00"
    },
    {
      "action_type": "offsite_conversion.fb_pixel_purchase",
      "value": "4890.00"
    }
  ]
}

The returned value is not an order count. It is the reported conversion value.

The cost_per_action_type field

The cost_per_action_type field returns the average advertising cost for each available action type.

For a selected reporting row:

The API may omit an action type when there were no reportable actions. A missing item must not automatically be treated as a confirmed zero without checking the reporting logic.

ROAS fields

Meta provides separate fields for purchase ROAS:

• purchase_roas
• website_purchase_roas
• mobile_app_purchase_roas

These fields also return action-stat arrays rather than a single universal number.

Common ecommerce action types

The following identifiers are commonly returned for standard ecommerce metrics:

Meta does not expose these identifiers as individual top-level Insights fields. Confirm the values returned by the ad account and API version before hard-coding them into a reporting system.

The fb_pixel part of a website action type does not necessarily mean that the event came only from browser-based Pixel code. Website events sent through Conversions API can be connected to the same dataset and deduplicated with browser events.

Content View Metrics

Content Views

Content Views show the number of attributed ViewContent events.

For an ecommerce website, ViewContent is normally sent when a user opens a product page. It should not be triggered on every page unless every page represents content that the business intends to measure as a product or commercial item.

In the API, the total metric is commonly found in:

• Field: actions
• Action type: omni_view_content

The total metric may include reportable content-view events from more than one conversion location. The exact composition depends on the account setup and activity being reported.

Website Content Views

Website Content Views are limited to attributed ViewContent events assigned to the website.

In the API, the metric is commonly found in:

• Field: actions
• Action type: offsite_conversion.fb_pixel_view_content

Use Website Content Views when the analysis concerns an online store and later stages also use website-specific metrics.

Do not compare total Content Views with Website Adds to Cart unless the difference in conversion locations is intentional. A funnel should use the same scope at every stage.

Interpretation limits

A Content View is an event count, not a count of unique users or unique product pages.

One person can generate several events by:

• Opening several products
• Returning to the same product
• Reloading a page
• Using more than one device
• Triggering a duplicate implementation

A high number of Content Views does not prove that users found the product relevant. Compare the metric with Adds to Cart and Purchases.

Add-to-Cart Metrics

Adds to Cart

Adds to Cart show the number of attributed AddToCart events.

The total metric is commonly available in:

• Field: actions
• Action type: omni_add_to_cart

Depending on the reporting setup, the total may include cart activity from more than one conversion location.

Website Adds to Cart

Website Adds to Cart show attributed AddToCart events assigned to the website.

The metric is commonly available in:

• Field: actions
• Action type: offsite_conversion.fb_pixel_add_to_cart

For a website-only ecommerce funnel, this is the more consistent metric.

An AddToCart event should normally be sent after the item is successfully added to the cart. Sending it when a user only clicks an add-to-cart button can create false events if the request fails or the item is unavailable.

Repeated cart events

Adds to Cart are actions, not unique carts.

The same person may:

• Add several products
• Add the same product more than once
• Remove and add a product again
• Create cart activity in several sessions

For this reason, Adds to Cart can exceed the number of users who reached the cart.

Cost per Add to Cart

Cost per Add to Cart is calculated as:

In the API:

• Field: cost_per_action_type
• Total action type: omni_add_to_cart
• Website action type: offsite_conversion.fb_pixel_add_to_cart

Do not calculate a combined result by averaging campaign-level or ad-level costs.

Use:

This rule applies to every cost-per-action metric in the article.

Checkout Metrics

Checkouts Initiated

Checkouts Initiated show how many attributed InitiateCheckout events occurred.

The total metric is commonly available in:

• Field: actions
• Action type: omni_initiated_checkout

The event should be sent when the customer starts the checkout process, not when the cart page is opened.

Website Checkouts Initiated

Website Checkouts Initiated are limited to attributed checkout events assigned to the website.

The metric is commonly available in:

• Field: actions
• Action type: offsite_conversion.fb_pixel_initiate_checkout

Use the website-specific metric when comparing it with Website Adds to Cart and Website Purchases.

Adds of Payment Info

Adds of Payment Info show attributed AddPaymentInfo events.

The metric indicates that a customer submitted or saved payment details during checkout. It may be unavailable or underreported when:

• The store does not send AddPaymentInfo
• A third-party checkout does not pass the event
• The checkout skips a separate payment-information step
• Express payment completes the order without the expected event sequence
• Consent or browser restrictions block the event

Common API mappings are:

• Field: actions
• Total action type: omni_add_payment_info
• Website action type: offsite_conversion.fb_pixel_add_payment_info

Do not assume that every checkout must contain an AddPaymentInfo event. The required sequence depends on the store and payment method.

Cost per Checkout Initiated

The formula is:

In the API:

• Field: cost_per_action_type
• Total action type: omni_initiated_checkout
• Website action type: offsite_conversion.fb_pixel_initiate_checkout

Cost per Add Payment Info

The formula is:

In the API:

• Field: cost_per_action_type
• Total action type: omni_add_payment_info
• Website action type: offsite_conversion.fb_pixel_add_payment_info

This metric is useful only when AddPaymentInfo is implemented consistently.

Purchase Metrics

Purchases

Purchases show the total number of purchase events attributed to ads within the selected reporting settings.

The metric is commonly available in:

• Field: actions
• Action type: omni_purchase

Purchases may combine reportable activity from several conversion locations. These can include website, app, Meta-hosted, messaging or offline activity when the corresponding sources are configured and included.

The exact composition depends on the campaign, account and event setup.

Website Purchases

Website Purchases show purchase events attributed to ads and assigned to the website conversion location.

The metric is commonly available in:

• Field: actions
• Action type: offsite_conversion.fb_pixel_purchase

Website Purchases can include website events received through:

• Meta Pixel
• Conversions API
• A supported partner integration
• A deduplicated combination of browser and server events

The action type name contains fb_pixel, but this should not be interpreted as browser-only data.

Why Purchases and Website Purchases may differ

Purchases and Website Purchases can be equal when all attributed purchases happen on the website.

They can differ when the total metric also includes purchases from other conversion locations, such as:

• Mobile apps
• Physical stores
• Business messaging
• Meta-hosted commerce experiences
• Other configured purchase sources

The difference can also be affected by event configuration and data quality.

Use Purchases when the business intentionally measures sales across several conversion locations.

Use Website Purchases when the analysis is limited to an ecommerce website.

Do not subtract Website Purchases from Purchases and assume that the result is a complete count of app or offline purchases. Confirm which sources and action types are present in the API response.

Conversion Value Metrics

Purchases Conversion Value

Purchases Conversion Value is the total monetary value attached to attributed purchase events in the selected reporting scope.

In the API:

• Field: action_values
• Action type: omni_purchase

The value depends on the data sent with Purchase events.

Website Purchases Conversion Value

Website Purchases Conversion Value is limited to attributed purchase value assigned to website events.

In the API:

• Field: action_values
• Action type: offsite_conversion.fb_pixel_purchase

Use this value with Website Purchases and Website Purchase ROAS.

Value and currency parameters

A Purchase event should contain a numeric value and a valid ISO 4217 currency code.

The current Meta Business SDK CustomData class supports fields such as:

• value
• currency
• order_id
• content_ids
• contents
• content_type
• num_items

The store must define what the purchase value includes.

Possible approaches are:

• Product revenue after discounts
• Revenue including tax
• Revenue including shipping
• Gross revenue before refunds
• Net revenue after known adjustments

Any approach can support internal reporting if it is applied consistently. Problems begin when different platforms, stores or event sources use different definitions.

The Insights API reports monetary results in the context of the ad account currency. Do not assume that the original event currency will remain visible as a separate dimension in the report.

Average Purchases Conversion Value

Average Purchases Conversion Value shows the average attributed value per purchase.

The formula is:

The current Insights API includes:

• Field: average_purchases_conversion_value

This is an action-stat field, so the integration must select the relevant purchase action type from the returned array.

For website-only reporting, a reproducible calculation is:

This result is often used as attributed Average Order Value.

Average Purchases Conversion Value can be incorrect when:

• Purchase value is missing
• Currency is invalid
• Some event sources include tax and others do not
• Test orders are sent as real purchases
• Duplicate Purchase events are not removed
• Refunds and cancellations are not accounted for
• Subscription renewals are classified inconsistently

Cost per Ecommerce Conversion

Cost metrics compare advertising spend with attributed actions.

Aggregation rule

Never calculate a combined cost per conversion as a simple average of row-level values.

Incorrect:

Correct:

The same rule applies when combining:

• Campaigns
• Ad sets
• Ads
• Days
• Countries
• Placements
• Devices

Use non-overlapping rows and the same attribution settings.

Purchase ROAS

Purchase ROAS

Purchase ROAS compares attributed purchase value with advertising spend.

The formula is:

In the API:

• Field: purchase_roas

The field returns action-stat records. Select the relevant purchase action type instead of assuming that the response contains one scalar value.

A Purchase ROAS of 4 means Meta attributed four units of purchase value for each unit of ad spend. It does not mean the campaign generated four units of profit.

ROAS does not subtract:

• Product costs
• Shipping costs
• Payment fees
• Agency fees
• Taxes
• Refunds
• Discounts not reflected in the event value

Website Purchase ROAS

Website Purchase ROAS compares attributed website purchase value with advertising spend.

The formula is:

In the API:

• Field: website_purchase_roas

Use Website Purchase ROAS for a website-only ecommerce analysis.

Purchase ROAS vs Website Purchase ROAS

Purchase ROAS can include purchase value from more than one conversion location.

Website Purchase ROAS is limited to website-attributed value.

The two metrics may be equal when all reportable purchases occur on the website. They may differ when the account also receives app, offline, messaging or other purchase events.

Do not compare total Purchases with Website Purchase ROAS. The count, value and cost metrics should use the same conversion scope.

ROAS aggregation

Do not average row-level ROAS values.

Correct formula:

This rule is especially important when campaigns have different spend levels.

Derived Ecommerce Metrics

A funnel rate compares two stages of the same customer journey.

Use website metrics together for a website funnel. Do not mix omni and website action types unless the analysis specifically requires it.

View-to-Cart Rate

The formula is:

This metric shows the share of attributed product-view events followed by attributed cart activity at the report level.

It is not a user-level conversion rate. The numerator and denominator are event counts.

Cart-to-Checkout Rate

The formula is:

A low rate can indicate problems with:

• Cart usability
• Unexpected shipping costs
• Product availability
• Discount-code behavior
• Account-creation requirements
• Event implementation

The metric alone cannot identify the cause.

Checkout-to-Purchase Rate

The formula is:

This rate helps identify losses during checkout.

Compare it with payment errors, shipping restrictions, checkout speed and payment-method availability.

Cart-to-Purchase Rate

The formula is:

This is a broader measure of lower-funnel completion.

Landing Page View-to-Purchase Rate

The formula is:

The current Insights API includes the direct field:

• purchase_per_landing_page_view

Meta also exposes:

• landing_page_view_per_purchase_rate

The two fields represent different directions of the relationship. Verify the field definition and output format before using either one in automated reporting.

A manual ratio remains useful when the report must use a specific website-purchase action type.

Link Click-to-Purchase Rate

The formula is:

The current Insights API includes:

• purchases_per_link_click

A manually calculated website-only version may differ from a direct total-purchase field if their conversion scopes are not the same.

Average Order Value

The website-attributed formula is:

This is an attributed average order value. It may differ from CRM AOV because Meta includes only attributed purchases and follows Meta reporting rules.

Correct aggregation

Do not average daily or campaign-level funnel rates.

Use:

For example:

This method gives each row weight according to its actual event volume.

Ecommerce Funnel Metrics in the Interface and API

API action-type availability can vary by account, conversion source and API version. Inspect the response before finalizing a production mapping.

Attribution and Tracking Limitations

Attribution setting

Meta attributes conversions according to the reporting configuration associated with the ad set and Insights request.

The current Insights API supports parameters such as:

• action_attribution_windows
• use_account_attribution_setting
• use_unified_attribution_setting
• action_report_time

The available attribution-window values include click-through and view-through options. Not every value is necessarily available for every campaign, account or Ads Manager workflow.

Do not treat one attribution window as a permanent universal default. Store the reporting configuration with the result.

Two reports are comparable only when they use the same:

• Attribution setting
• Reporting period
• Time zone
• Report level
• Action-report time
• Conversion scope
• Breakdowns

Action report time

The action_report_time parameter controls how actions are assigned to reporting dates.

The current API defines options including:

• impression
• conversion
• mixed
• lifetime

A purchase can therefore appear under the date of the ad interaction or the date of the conversion, depending on the reporting mode.

Daily Meta data cannot be reconciled with a CRM by date unless both systems use compatible date logic.

Meta Pixel and Conversions API

Meta Pixel sends browser events. Conversions API creates a direct connection between Meta and data from a server, website platform, app, CRM or another business system.

Meta recommends using Conversions API with Pixel for website events when possible. According to Meta’s Conversions API documentation, the two sources can support the same optimization and measurement surfaces.

Conversions API is not a replacement for consent requirements or privacy rules.

Deduplication

When the same website event is sent from both Pixel and Conversions API, Meta must identify it as one event.

Meta uses the combination of:

• event_name
• event_id

The current Meta Business SDK Event class states that event_id and event_name are used to determine whether browser and server events are identical.

For reliable deduplication:

1. Generate one event ID for the business event.
2. Send the same event name through both sources.
3. Send the same event ID through both sources.
4. Do not reuse the ID for a different business event.
5. Monitor deduplication in Events Manager.

If browser and server events use different IDs, Meta may count both. If unrelated purchases reuse one ID, Meta may remove valid events.

Value and currency

Purchase value must be numeric. Currency must use a valid three-letter ISO 4217 code.

Define whether the reported value includes:

• Taxes
• Shipping
• Discounts
• Gift cards
• Store credit
• Refunds
• Subscription renewals

Apply the same definition across browser and server events.

Sending correct purchase counts with incorrect value produces valid-looking CPA data but incorrect Conversion Value and ROAS.

Reporting delays and restatements

Conversion reporting is not always final immediately after the reporting date.

Values can change when:

• A conversion occurs later within the attribution window
• A server event arrives after the initial report
• Meta matches an event later
• Deduplication is completed
• Modeled reporting is updated
• Event configuration is corrected

Avoid treating the most recent day as final. Store extraction timestamps and refresh recent reporting periods.

Missing and zero values

The API may omit an action_type when no value is available for that row.

A missing item can mean:

• No attributed action was reported
• The metric is unavailable
• The requested breakdown is incompatible
• The event source did not produce the action type
• Privacy or reporting rules restricted the result

A reporting pipeline may convert a confirmed missing action to zero for analysis, but it should preserve the distinction during validation.

Breakdown restrictions

The Insights API supports standard breakdowns and action breakdowns.

Current action breakdowns include:

• action_type
• action_destination
• action_device
• conversion_destination
• signal_source_bucket

Meta does not support every combination of metrics and breakdowns. An API request may fail or return a different level of detail when the selected combination is incompatible.

Do not assume that all breakdown rows can be added to recreate an unbroken total. Modeled data, unique metrics, attribution rules and overlapping action categories can affect aggregation.

Interface and API differences

Ads Manager and the Marketing API should be compared only with matching settings.

Check:

• Date range
• Account time zone
• Attribution setting
• Report level
• Filters
• Breakdowns
• Conversion location
• API version
• Action-report time

A difference does not automatically indicate an API error.

Beyond Core Ecommerce Metrics

The current Insights API includes additional fields for catalog and product reporting.

Examples include:

• product_views
• converted_product_quantity
• converted_product_value
• converted_product_omni_purchase
• converted_product_website_pixel_purchase
• converted_product_offline_purchase
• catalog_segment_actions
• catalog_segment_value
• catalog_segment_value_omni_purchase_roas
• catalog_segment_value_website_purchase_roas

These fields support questions that standard purchase metrics cannot answer.

Converted product quantity

Purchase events count transactions. Converted product quantity can measure the number of product units connected with conversions.

One purchase can contain several products, so product quantity may exceed purchase count.

Converted product value

Converted product value supports product or catalog-level revenue analysis.

Accurate reporting requires consistent:

• Product IDs
• Catalog IDs
• Content type
• Item quantities
• Item prices
• Purchase value

Product and catalog breakdowns

The current API includes product-related breakdowns such as:

• product_id
• product_brand_breakdown
• product_category_breakdown
• product_group_content_id_breakdown
• Product custom labels

Availability depends on the campaign and catalog configuration.

Custom conversions

Custom conversions can classify standard or custom events using business-defined rules.

Use them when the standard Purchase event must be divided into categories, such as:

• New customer purchases
• Subscription purchases
• High-value orders
• Purchases from a specific product category

Document the rule before using the result in a report. A custom conversion is only as reliable as its underlying event and matching conditions.

App, offline and messaging purchases

Use source-specific metrics when the business must separate:

• Website purchases
• Mobile app purchases
• Physical-store purchases
• Purchases through business messaging
• Other configured conversion sources

Use total Purchases only when combining those sources is an intentional reporting decision.

Final Takeaway

Use website-specific metrics for a website ecommerce funnel:

• Website Content Views
• Website Adds to Cart
• Website Checkouts Initiated
• Website Adds of Payment Info
• Website Purchases
• Website Purchases Conversion Value
• Cost per Website Purchase
• Website Purchase ROAS

Use total or omni metrics when the business intentionally combines several conversion locations.

In the Marketing API, most ecommerce events are not separate scalar fields. Extract the required action_type from actions, action_values and cost_per_action_type.

Calculate combined costs, rates and ROAS from summed numerators and denominators. Do not average row-level ratios.

Finally, validate event counts, purchase values, currency, source coverage and deduplication before evaluating campaign performance. ROAS depends on tracking quality as well as advertising performance.