Insights

Read event analytics in the Sway web app: AI Mode, the eight reporting tabs, the shared date range, campaign attribution, sales, live check-ins and pixels.

Insights is where an event's numbers live: how many people saw the page, where they came from, what they bought and how many of them walked through the door. It is nine tabs sitting behind one shared date range, and the largest screen in this group.

The first tab, AI Mode, is the only one that answers what should I do. The eight after it report. Insights opens on AI Mode.

Almost all of it is read-only. The only things you can change here are your capacity and break-even on AI Mode, and everything on Tracking Pixels.

Open Insights

  1. Open Manage, then click your event.
  2. Click Insights in the left sidebar, under Analytics.

The sidebar row needs the analytics permission, and is greyed out without it. The page itself is more forgiving than the row: opened directly by URL it renders for anyone holding any permission at all on the event, and answers You don't have permission to view analytics for this entity. only to an account holding none. Exporting is a second, separate permission, covered under Campaigns.

Live Check-ins is this page, not Scanners

The Live Check-ins row sitting right below Insights is not a screen of its own. It opens Insights on its Check-ins tab, which is where the live door dashboard lives. It is also not Scanners, which is where scanner devices are created and handed out.

One quirk to expect: that row never highlights as the current page, because the sidebar decides what is active by comparing plain paths and this one carries a tab in its address. You are in the right place even though nothing looks selected.


Set the window before you read anything

The date-range picker sits above the tab bar and governs every tab except one. The presets are 7 days, 30 days, 90 days, 1 year, All time and Custom. It opens on 30 days, and the exact dates it resolved to are printed next to the buttons.

To look at an arbitrary window:

  1. Click Custom.
  2. Pick a start date in the first field.
  3. Pick an end date in the second field.

Three behaviours are worth knowing before you trust a figure:

  • Check-ins ignores it. The picker is greyed and inert while that tab is open, because the door dashboard is always live.
  • A past event is capped at its own end date. Presets stop counting at the day the event finished rather than at today, and a blue line says so: Past event — date ranges are capped at the event end date (…). So 30 days on a finished event means the last 30 days of the event, not the last 30 days of the calendar.
  • Custom escapes that cap. The second field accepts anything up to today, so a custom window is the way to see what happened after an event ended.

Beside the picker sits a permanent line: Snapshot data updated daily at ~03:00 UTC. Take it literally. Views, visitors, sources, geography and devices come from a snapshot rebuilt overnight, so today's traffic is not in them yet.

Days are counted in the event's own timezone, not yours and not UTC. An organiser in another country opening the same event sees exactly the same figures, and the day boundaries line up with the ones used on the event dashboard. The timezone is the one set in Settings → Dates.

What each tab answers

TabWhat it is for
AI ModeWhat to do next: a health score, your pace against a reference curve, and a ranked list of actions
OverviewReach and interest: views, visitors, Interested, Going, countries, cities
Traffic SourcesWhich referrers and which UTM tags brought the visits
CampaignsWhich of those tags produced money
EngagementDevices, browsers, and the hours people open the page
SalesRevenue, orders, refunds, discounts, and abandoned checkouts
Check-insThe live door dashboard
URL StatsClicks on your custom short URL
Tracking PixelsYour own advertising pixels, and inherited promoter ones

AI Mode

The tab Insights opens on, and the only one that reads your event rather than reporting it. It ignores the date-range picker entirely: everything on it is measured against the days left until doors, not against a window you chose.

The health score

A ring from 0 to 100 headed Health, built from five components: Pace, Checkout, Reach, Page ready and Loyalty. Hover the ring to open What the score is made of and see each one with its own figure.

A component that cannot be measured is left out of the score instead of counting as zero, and says why — No capacity recorded, so there is nothing to measure fill against, Too few checkouts started for a percentage to mean anything. The line under the ring tells you how many made it in: Built on 3 of 5 components. A score built on three components is a narrower statement than one built on five, and reading it as the same number would be wrong.

Beside the title sits how long ago it was recomputed, and, once there is a snapshot from yesterday to compare against, the move since: +4 since yesterday. On the first reading it says First reading. Come back tomorrow for a trend.

Below the ring, This phase ticks off what a campaign at this stage normally has done: Event announced, Artwork published, Tickets on sale, Your list emailed, Final-week message sent. The phase name changes as doors approach, from Announce through Mid campaign to Last call. Every tick is read from your data, never from a checkbox you fill in yourself, and anything that cannot be measured is left off the list rather than shown unticked.

Pace

Five figures across the top of the card: Sold, Against the curve, Break-even, Per day, last 7 and Your earnings. Your earnings is the net actually paid out to you, not the catalogue value of what sold.

Against the curve is the one to read first. It compares what you have sold with what a reference campaign would have sold by this point, and answers with a multiplier: at 1.5× you are ahead of the curve, at 0.6× behind it. The figure beside it says what the reference expected.

Under the figures, a bar tracks the run to break-even, and Odds of clearing it puts a percentage on getting there.

Those odds are not a forecast. Two defensible projections bracket where you finish, and the percentage is simply the share of that range sitting above your break-even, read evenly. There is no fitted model behind it, and with the amount of data available there could not be. Hover the figure and it says so.

The chart plots four lines against Days to doors: Your sales, the reference curve for your event type, the path to break-even and the path to a full room. The second chart below it, Required per day, answers the question the first one raises: how many tickets a day the curve is asking for between now and doors, against Your rate now.

Do this next

A ranked list of findings, worst first, each tagged Critical, Warning, Opportunity or Note. Where a finding leads somewhere, Open takes you to the screen that fixes it. Ask the AI hands it to the assistant panel with the finding already written into the question. The assistant's own answers end with the same kind of button where one applies, labelled for what it does rather than for the screen it opens, and it replies in whatever language your admin is set to unless you ask it in the chat for another one.

Some findings carry About 40 tickets are riding on this. That is an order of magnitude, not a promise, and findings resting on a published rule of thumb rather than on your own numbers are labelled Rule of thumb.

Dismiss sets a finding aside. It is not a delete: dismissal is recorded per event, so the whole team stops seeing a decision they have already taken together, and the list reopens under Dismissed (3) at the bottom with who set each one aside and when. Restore puts it back. Dismissing needs the editing permission — a read-only account can open this tab but cannot hide a warning from the owner.

With everything cleared the list reads Nothing needs your attention right now, or Everything that fired has been set aside when the reason it is empty is that you hid it.

What changed

What appeared and what you resolved since last night's snapshot. Before there is a second snapshot to compare against it says so rather than showing zeros.

Where the numbers come from

The Where these numbers come from button at the very bottom opens the provenance: which curve your event was read against and why that one, where your capacity figure came from, and the fact that the curve is published industry data for European electronic-music events rather than a measurement of your event.

Nothing on this tab compares you to other organisers on Sway. There is no meaningful sample to compare against, so the tab does not pretend there is.

Fix the capacity or the break-even

Change capacity and break-even in the Pace card header opens a panel with two fields.

Room capacity is what the room holds. Left empty it uses the total stock across your ticket types, which is right whenever everything you loaded is everything the room takes — and wrong the moment you have loaded a first tier only. Entries needed to break even is what the event costs you, expressed in tickets. Nobody can fill that in for you: it is not the rent alone.

Both need the editing permission. Without a capacity there is no fill to measure, so Pace says no capacity set and the health score is built on fewer components.


Overview

Four cards across the top: Total Views, Unique Visitors, Interested and Going. Underneath, Page Views Over Time plots views and unique visitors together, and Interested & Going Over Time plots the two RSVP counts.

Top Countries and Top Cities each show the best eight rows as bars. The percentage is a share of all measured traffic in the window, not a share of the eight rows on screen, so the bars deliberately do not add up to 100%.

Unique visitors are distinct people, which makes them non-additive: a visitor who came back on three days is one unique visitor for the period and three in the daily chart. Adding days together will always overstate your audience.

Any panel with nothing in it reads No data available for this period.


Traffic Sources

Two tables. The first, headed Direct / Referrers, lists the domains visits arrived from with a Visits count and a % share. The second, headed UTM Attribution, lists UTM tags by Source, Medium and Campaign, again with Visits.

This tab counts visits. It says nothing about money. For the money, use the next tab.

Two labels here are hardcoded and stay English whatever language your admin is set to: the UTM Attribution heading, and the Source column of the referrer table. Everything else is translated: the Direct / Referrers heading, the Visits and % columns beside it, and all four columns of the UTM table. The two tables therefore behave differently on the same word — the Source column of the UTM table does follow your language, the one above it does not.


Campaigns

Campaigns joins UTM tags to paid orders. Four cards summarise it: Attributed revenue, Attributed orders, Direct / no campaign tag and Off-web.

A permanent note explains the ground rules: Revenue matches the Sales tab exactly. Only orders placed after campaign capture was enabled can be attributed. If an event has none of that data the tab adds Campaign data is not available yet.

Switch between first touch and last touch

  1. Open the Campaigns tab.
  2. Click Last touch or First touch at the top right of Attributed campaigns.

Last touch credits the tag the buyer arrived on immediately before buying, and is the default. First touch credits the tag that introduced them. Only the campaign table reloads; nothing else on the page moves.

Read the table

Columns are Source, Medium, Campaign, Content, Checkouts, Total Orders, Tickets Sold, Net revenue and Conv. rate. Three more, Spend, ROAS and Cost / order, appear only once ad spend has been recorded for the event.

Conv. rate is frequently blank, and on purpose. It is hidden below 30 orders in a row, with the tooltip Conversion rate hidden below 30 orders: too few to be meaningful., and it is hidden on any window reaching back more than 30 days, because the checkout records that form its denominator are deleted at that age while orders are kept forever. A rate computed across that boundary inflates and can pass 100%, so none is shown.

Below sits Other sources, which is never merged into the table above:

  • Direct / no campaign tag, with the reason printed underneath: WhatsApp, Instagram DMs, TikTok and Discord strip the referrer. A large share here is normal.
  • Off-web, likewise: Door sales, POS terminal and guestlist. These never go through a browser checkout, so they cannot carry a campaign.

When no campaign has produced a sale yet, the table reads No attributed sale yet. Attribution starts the day capture ships: earlier orders cannot be traced back.

Export the campaign data

  1. Click Export CSV, next to the touch switch.
  2. The file downloads named after the event and the touch model you had selected.

The export carries every row, including the untagged and off-web buckets, so the spreadsheet reconciles with the Sales tab. Its conversion-rate column is left empty wherever the screen suppresses the rate.

Export CSV is a separate permission from viewing. Without it the button is not disabled, it is absent, and the rest of the tab still works.


Engagement

Three doughnut charts open the tab: Device Types, Operating Systems and Browsers. At the bottom, In-App Browsers lists visits that arrived inside another app's browser rather than a real one.

In between sits When people open your page, subtitled Page views, not sales. followed by the timezone it is drawn in. Web visitors and app visitors are two separate series and are never added together, which the card restates underneath. A dashed First activity marker shows where your own announcement landed, and when that announcement dominates the window the card says so before the chart rather than after it.

Where that traffic came from splits the same 24 hours into Campaign traffic, Referral and Direct. Week grid appears only when your window covered each weekday often enough to mean something; otherwise the card explains, with your actual numbers, why it is withholding it. With too little traffic altogether it says Not enough page views yet to show a pattern.

Narrow the hours to a local audience

  1. Open the Engagement tab.
  2. Turn on Local audience only at the top right of the timing card.

This refetches the card against visitors whose device timezone reads the same clock as the event, so the hours shown are the hours those people actually lived. It is off by default because it discards real visitors: anyone travelling, on a VPN, or on a mobile or corporate network that misplaces them, drops out. The card prints that warning as soon as you switch it on.


Sales

Eight cards: Total Revenue, Total Orders, Tickets Sold, Scan Rate, Avg. Order Value, Refunded Orders, Refunded Amount and Coupon Discount. Then Orders by Day and Revenue by Day side by side, and a By Product table breaking Sold and Revenue down per ticket type.

With nothing to show, the tab reads No ticketing data found for this period.

Selecting All time adds a line that changes what you are looking at: Sales data shows all-time totals — not affected by the date range filter above. On every other range the figures do follow the picker.

Total Revenue is what you receive, not what buyers paid. It is the face value of the tickets with Sway's service fees excluded, which is why it is smaller than your buyers' card statements and smaller than your Stripe payouts, without either being wrong. The Net revenue column on Campaigns is the same figure cut by campaign, which is what lets the two tabs reconcile. Order-by-order detail lives on Orders.

Started a checkout, never finished

At the bottom of the tab, outside everything else, sits Started a checkout, never finished, subtitled Counted per person, not per checkout. Web only. It stays on screen even when the tab above it has no sales data, because an event with abandoned checkouts and no completed ones is exactly the case that needs it.

Four figures: Abandon rate, People who never bought, Value not recovered and Reached the payment step, over a bar splitting the people who bought from the people who did not.

The card refuses to compute a rate on thin data and says so instead: Not enough checkouts yet to show a rate: N of 30. It also states its own accounting under the figures, including that one person is counted once however many times they retried, and that anyone who bought this event at any point counts as a buyer even if an earlier checkout of theirs expired. Where an event predates the current 30-minute checkout window, it names the date it starts counting from and how many older checkouts it left out.

On events where this cannot be measured it reads Checkout abandonment is not available yet for this event.


Check-ins

This tab is the live door dashboard, and it is the one place the date picker does not apply.

Total Scanned against Total Tickets, with Scan Progress as a bar. Below that, Check-in Velocity by time block, Scans by Scanner, and Recent Check-ins listing Ticket type, Scanned at and Scanner. Before the first scan it reads No check-ins recorded yet.

A button at the top right starts and stops live mode. While it is running the header reads Live Mode Active with Refreshing every 10 seconds beside it, and a green dot pulses. Refreshing pauses on its own while the browser tab is in the background and catches up when you come back, so leaving the dashboard open all night on a laptop costs nothing.

That button, and only that button, is in English whatever language your admin is set to.

Scans by Scanner is often empty where the other panels are full. When it is, it explains itself: Scanner attribution not recorded. The scan app does not currently send scanner identity with each scan. Read it as missing attribution, not missing scans.

If you hold the guestlist permission, a Guestlist card sits above the charts reading N of N guests checked in and links straight to Guestlist. Guests are a separate list from ticket scans and are not inside the numbers above it.


URL Stats

With a custom short URL on the event, this tab shows total clicks, unique clicks and clicks over the last seven days.

Without one it shows This entity doesn't have a vanity URL yet. and a button:

  1. Click Create a Slug.
  2. You land on Settings → URL, where the slug is created, checked for availability and given a QR code. See Event settings.
  3. Come back to URL Stats once it exists.

The empty state above is translated and reads in your own language. The card that replaces it is not: its three figures are hardcoded French whatever language your admin is set to. Left to right, Total clics is total clicks, Uniques is unique clicks, and 7 derniers jours is the last seven days.


Tracking Pixels

Your own advertising pixels, and the promoters' pixels this event can borrow. Everything else in Insights is a read-out; this tab writes.

Add a pixel

  1. Open the Tracking Pixels tab.
  2. Click Add Pixel.
  3. Choose a Pixel Type: Meta Pixel, Google Analytics 4, TikTok Pixel, Snapchat Pixel, Google Tag Manager or Custom Image Pixel. A type you already configured is listed as already added and cannot be picked twice.
  4. Paste the identifier. The field is labelled for the provider you chose, and rejects a malformed value with Invalid ID format for this provider.
  5. Leave Active on unless you are staging it for later.
  6. On Meta only, turn on Server-side (CAPI) and paste an Access Token if you want conversions sent from our servers as well as from the browser.
  7. Click Save. A Pixel saved. confirmation appears and a card joins the grid.

Each card shows the provider, the identifier, and an Active or Inactive badge. Click a card to edit it. The type cannot be changed after creation, and re-opening an existing Meta pixel leaves the token field blank on purpose: Leave blank to keep the current token.

Remove Pixel sits at the bottom left of the editor and asks for confirmation before removing the configuration.

Managing pixels is its own permission. Without it the Add Pixel button is disabled and the editor opens read-only, but every configured pixel stays readable.

Inherit a promoter's pixels

Underneath the grid, Inherited from promoters lists every promoter attached to the event with a switch each. On an event with no active pixel of its own, those switches decide whose pixels fire on the public event page: This event has no pixel of its own, so its public pages fire the pixels of the linked promoters enabled below.

To stop one promoter's pixel firing:

  1. Scroll to Inherited from promoters.
  2. Turn its switch off. The change saves immediately.

The moment the event has an active pixel of its own, the whole list fades and every switch locks, and the hint changes to This event has its own active pixels, so promoter inheritance is ignored. Nothing was reset: your choices are still stored and come back the day the event's own pixel is deactivated or removed. Deactivating an event pixel is therefore how you hand tracking back to the promoters.

Analytics only ever run forwards. A pixel added the week before doors, a short URL created after the announcement, or inheritance left off during a campaign, all produce a permanent hole. Nothing on this page is backfilled, and the checkout records behind the campaign conversion rate are deleted after 30 days, so a window you did not look at within the month cannot be reconstructed later. Set pixels and URLs up before you start promoting, and export anything you need to keep.

Insights on your other pages

Promoter, artist and venue pages have an Insights screen too, with the same date picker and the same overnight snapshot note, but only four tabs: Overview, Traffic Sources, URL Stats and Tracking Pixels. Campaigns, Engagement, Sales and Check-ins are event-only, because they are built on ticket orders and door scans.

A promoter's Overview additionally pools the hours across that promoter's past events, each measured on its own clock.

To do thisGo to
Read one order, or refunds line by lineOrders
Create the short URL that feeds URL StatsSettings → URL, see Event settings
Create scanner devices for the doorScanners
Check a guest in by handGuestlist
Let a colleague read or export analyticsPermissions, see Manage permissions