Playbook: Event Engagement & Analytics Report (Advisor)

Playbook: Event Engagement & Analytics Report (Advisor)

Surface: Compass Advisor, used by a destination logged into their own Playeasy profile.

What this produces: a measured, actual-activity report for one date window — event page traffic, then (if wanted) hotel performance, then (if wanted) local business performance — built entirely from destination-level reports.

What it is not: a projection. Nothing here is modeled or estimated. This is what actually happened on the platform, never blended with the Destination Customized Inputs for Event Impact Report's modeled spending/tax figures — those stay in their own tables if both are run together.

---

Why this runs at the destination level, not per-event

Per-event profile_report calls (profileType: Event) currently hit an access-denied response under Advisor's session — confirmed as a permission gap specific to Event-level reporting, not a session or data problem (profile_search for events works fine; the wall is on report access to individual Event profiles specifically). Destination-level reports covering the same ground do not hit that wall and were confirmed working:

Report	reportType	Covers
Event performance	Events	Page views, visitors, sessions, registration/ticket clicks — destination-wide, with a per-event breakout for the top events by visitors
Hotel performance	Hotels	Block-link click traffic (overview) and actual bookings/room nights/$ booked (pickup) — destination-wide, with per-hotel and top-events-by-room-nights breakouts
Local business performance	Partners	Page traffic to business/partner profiles — destination-wide, per-business breakout
Promotion redemptions	Promotions	Promotion clicks and redemption intent (link + QR) — destination-wide, with businessReport, hotelReport, and per-event breakouts

All four take the same call shape: profile_report, profileType: Destination, profileId = the destination's own id, startDate/endDate = the chosen window. No roster, no per-event loop, no batching — each is a single call.

This trades away true per-event depth. Every report above shows only the top events, hotels, or businesses by its own ranking metric — never the complete list — and everything outside the top entries only shows up inside the destination-wide totals, not as its own row. If event-by-event depth beyond what these breakdowns surface is genuinely needed, that's the known gap to raise with support@playeasy.com, not something this playbook can currently work around.

---

Chaining — where the date window comes from

• Chained off the Event Impact Report. Adopt its date window directly — skip asking.
• Standalone. Ask for the date range: recommend one month or less so results stay easy to review.

One window, used as-is on every call below — there's no per-event lookback anymore.

---

Step 1 — Event performance (always runs)

Pull profile_report, Destination, Events for the chosen window.

Present:

• Destination-wide totals: visitors, page views, sessions, registration clicks, ticket clicks.
• Region and traffic-source breakdowns.
• The per-event table, from relationReport — top events by visitors only, not exhaustive. State plainly that events outside this list are folded into the totals above, not absent from the platform.
• If two rows share a name and date range (a multi-venue event, e.g. two venues under one tournament), note them as the same event across venues rather than presenting them as unrelated or double-counting them in any total you compute yourself.

Close with: 1️⃣ Add hotel performance for this window 2️⃣ Skip to local business performance 3️⃣ That's everything — close out the report 4️⃣ Create a presentation or document from what's here so far

Step 2 — Hotel performance (only if requested)

Pull profile_report, Destination, Hotels for the same window.

Present, keeping the two halves distinct:

• Block-click traffic (overview) — destination-wide visitors/clicks, plus per-hotel breakdown. Genuinely zero here is a real result, not a block — state it plainly rather than treating it as missing data.
• Bookings (pickup) — room nights, average rate, $ booked, reservations, occupancy. eventReport is top events by room nights, not all of them — eventCount says how many existed in total. directReport ("Booked outside an event") is bookings with no event tied to them — a real, separate category, never inferred by subtracting the event total from the whole, and never folded into any event's row.
• Per-hotel figures come only from overview.hotelReport, pickup.hotelReport, and pickup.directHotelReport — the other breakdowns (region, source, event) are destination-wide across every hotel and must never be attributed to a single property.

Close with: 1️⃣ Add local business performance for this window 2️⃣ That's everything — close out the report 3️⃣ Create a presentation or document from what's here so far

Step 3 — Local business performance (only if requested)

Two calls, both for the same window:

• Profile views — profile_report, Destination, Partners → per-business page traffic (visitors, page views, sessions).
• Promotion redemptions — profile_report, Destination, Promotions → returns businessReport and hotelReport together in one call. Present the business half here. If Step 2 ran, also surface the hotel half here as a bonus cross-reference (it rode along in the same call) rather than re-pulling anything — label it clearly as hotel promotion activity, distinct from Step 2's booking/click figures. If Step 2 didn't run, still show the hotel half if it has activity — flagged as "hotel promotion activity (not requested as hotel performance, shown here since it came with the business pull)."

Redemption intent is the sum of two parallel paths, not a funnel: promotionExternalClicks (the partner sends people to an outside link) and promotionQrShown (an in-person QR code instead). A partner using only one path showing zero on the other is their delivery mechanism, not underperformance — report both columns plus the combined total.

A promotion row with no event tied to it ("Not tied to an event") is genuine destination-level activity, not a tagging failure — present it as its own line.

Close with: 1️⃣ Create a presentation or document from everything covered so far 2️⃣ Ask about a different slice of this data 3️⃣ Run this again for a different date window

---

Rules that do not bend

1. This is measured, actual data — never blended with a modeled report's figures (visitor spending, tax projections). If both run together, keep them in separate, clearly labeled tables.
2. Everything runs at profileType: Destination against a single date window — no per-event calls, no roster, no batching. Per-event Overview/Analytics calls are known-blocked under this session; don't attempt them.
3. Every report above surfaces only its own top entries, never the complete list. State that plainly rather than implying full per-event/per-hotel/per-business coverage.
4. Hotel performance (Step 2) and local business performance (Step 3) are separate, optional asks — don't pull either without the destination choosing to see it, and don't assume "no" to one implies "no" to the other.
5. Redemption intent = promotionExternalClicks (link) + promotionQrShown (QR) — two parallel paths depending on the partner's own setup, never called "redemptions" outright and never treated as a funnel. promotionQrShown is business-only; a hotel's is always structurally 0.
6. Business and hotel promotion activity are different products to a visitor — keep them as separate rows/tables, never merged into one blended promotion figure, even though both come from the same Promotions call.
7. A promotion or booking row with nothing tied to an event ("Not tied to an event" / directReport) is genuine destination-level activity, not a tagging failure or missing data.
8. Absent is not zero. A report returning nothing is "no data available," not "zero activity" — state which one it is for every metric.
9. If a call returns an access-denied response rather than empty data, stop — don't retry it or adjacent calls against the same wall. Name it as an access issue, not a data-emptiness issue, and point to support@playeasy.com with the specific report/profile type that failed.
10. Every response in this flow ends with the currently available options, in bold, with emoji numbers, one per line — and "Create a presentation or document" is one of them at every step, not only at the end, since the destination may want a deliverable of whatever's been pulled so far without running every step.
11. Date every figure and every table. Re-run rather than reusing an old pull.

---

Tool reference

Need	Call
Event performance (traffic, top events)	profile_report, Destination, reportType: Events
Hotel performance (block clicks + bookings, top events/hotels)	profile_report, Destination, reportType: Hotels
Local business profile views (top businesses)	profile_report, Destination, reportType: Partners
Promotion redemptions — business and hotel together	profile_report, Destination, reportType: Promotions

All four: profileId = the destination's own id, startDate/endDate = the chosen window, explicitly set rather than left to the tool's default lookback.

Handoff

"Create a presentation or document" is offered after every step (1, 2, and 3), not only at the end — a destination may want a deliverable of just the event traffic, or event + hotel, without ever running the business step. Whenever it's chosen, use the current help-desk playbook for that purpose (published title: "Create A Presentation or Document (Advisor)" — search the help desk for it by that exact title before assuming it's unavailable; retry once with broader terms if the first search comes back empty), and package whichever of Steps 1–3 have actually been run — never more than what's been pulled. If this run was chained off the Event Impact Report, offer to package both together as one deliverable, clearly labeled as two distinct data sources — never merged into one table.