If you've run a studio on MarianaTek for any length of time, you've exported a CSV. Probably dozens of them. Here's the quick rundown of what's available, where it works, and where it doesn't.
Three export paths
In our experience working with MT-based studios, almost every data request ends up going through one of these three routes.
1. Admin report exports
Inside the MT admin, most reports have a "Download CSV" option. This is where most operators start. You pick a date range, pick a report type — revenue, reservations, class attendance, whatever — and download.
Good for: ad-hoc questions with a specific date window.
Breaks when: you want to combine two reports (e.g., match a client to their payment history to their booking history), or when you want the same report every week at the same time. Neither is automatable from the UI.
2. API pulls (MT Admin API)
MarianaTek exposes an API that returns structured JSON for most core entities — users, reservations, class sessions, orders, memberships. This is what purpose-built tools (Reserve included) use under the hood.
Good for: anyone building custom tooling, or anyone who wants fresh data on a schedule.
Breaks when: you don't have a developer. The API is documented but not end-user friendly. Pagination, rate limits, and entity relationships require a real engineering effort to handle correctly at scale.
3. Third-party middleware
Some operators use no-code middleware (Zapier, Make, n8n) or MT-specific integrations to pull data into Google Sheets or similar.
Good for: light operational use, one-off automations.
Breaks when: row volume grows (these tools often have operation-count limits that get expensive fast) or when you need historical data — most middleware only forwards new events, not a backfill.
Common friction points
Regardless of which path you pick, a few patterns come up repeatedly:
Stale data. An export is a snapshot. The moment you download it, it's starting to age. If you're making a decision on Monday with Friday's CSV, you're making it on week-old data.
Manual joining. Most operator questions require joining two or three report types. MT's exports don't pre-join them for you. You end up doing it in Excel, and the joins get fragile when someone edits a column.
No alerting. Exports are pull, not push. You have to remember to run them. In practice, the ones that matter most — weekly retention, at-risk counts — are the ones that stop getting run during busy weeks. Which are exactly the weeks they matter most.
Row limits and filters. Some exports truncate at a row count. Others don't have the filter you want, forcing you to export everything and filter in Excel.
When exports stop being enough
A pragmatic signal: if you or someone on your team spends more than an hour per week downloading and reconciling MarianaTek CSVs, the export pattern has outgrown its usefulness.
At that point the three options are:
- Hire it. Pay an analyst or part-time operations person to maintain the weekly export rhythm. Solves the people problem, doesn't solve the latency problem.
- Build it. Commission a dashboard on top of MT's API. Works if you have the engineering resources or the budget to hire them.
- Buy it. Use a purpose-built analytics layer that sits on top of MT and surfaces what you'd have exported manually — but always current, always structured, and with alerting.
Reserve is the third option for studios that don't want to run the first two. See how pricing works.