How to Set Up Your PLAY Project for Clear, Actionable Data
Your analytics are only as readable as the project structure behind them. In PLAY, two parts of analytics are directly affected by how you build your project:
Path View (scene flow): mirrors your project’s Path View in the editor.
Engagements by Layer: logs clicks/taps/presses against layer names (and aggregates identical names).
This guide explains how to structure scenes and name layers so your analytics tell a clear story after export.
1. Keep the Path View Simple (use fewer scenes)
Rule of thumb: If your Path View is easy to read in the editor, it’ll be easier to read in analytics too.
Recommendations
Use as few scenes as possible. If you can build an idea without adding a scene, do it.
Prefer features that reduce scene sprawl (for example: carousel components, show/hide layers, state changes) instead of building “UI” by chaining many scenes.
Avoid complex looping scene graphs (where scenes connect back to earlier scenes in multiple directions). These can become very hard to interpret in analytics.
Why this matters
Analytics Path View is a visual map of your scene network. Highly “webbed” or cyclical structures may still be valid creatively, but they make it harder to answer questions like:
“Where did users drop off?”
“Which branch performs best?”
“How often do users reach the end card?”
2. Name Scenes so the Path View can be Understood by Anyone
Scene names appear directly in the Path View, so naming is part of making analytics readable.
Good scene naming habits
Use names that describe what the user is seeing/doing, not internal shorthand.
If scenes are sequential, number them so the flow is obvious.
If scenes represent variants, include the variant label clearly.
Example patterns
01_Intro
02_Tutorial
03_Product_SelectColor
04_Result_Win
05_EndCard
Avoid
Scene 2 - M3 (unclear to anyone who didn’t build it)
Test, New Scene, Untitled (not actionable in analytics)
3. Use Clean, Unique Layer Names
Engagements by Layer records interactions (like button clicks) against the layer name, and layers with the same name are aggregated together.
That means layer naming can make the difference between:
“Users clicked Swipe Right – Model 3 a total of 2,104 times”
vs
“Users clicked Hotspot a total of 8,522 times” (but you can’t tell which model performed best)
Best practices for layer naming
Give every interactive layer a specific, descriptive name.
If an interaction exists on multiple scenes but should be tracked separately, make the layer name unique per context.
If you want aggregation (e.g., one CTA used everywhere), use the same name across layers or use a global layer.
Need to refactor an existing project? Ask Craftsman Intelligence to fix your layer names for you!
Recommended naming patterns
CTAs
CTA_Primary_Download
CTA_Secondary_LearnMore
Logo_Click
Swipes / hotspots / choices
Hotspot_SwipeRight_Pizza1
Hotspot_SwipeRight_Pizza2
Hotspot_SwipeLeft_Pizza1
Btn_Choose_Blue
Btn_Choose_Red
End card
EndCard_CTA_Download
EndCard_Close
Quick Rule
If you’ll ever ask in a report, “Which one performed best?” then those “ones” need distinct layer names.
4. Be aware: auto-advancing scenes can inflate scene completion
If scenes automatically transition after a timer, scene completion percentages can look unusually high because users “complete” scenes without actively interacting. This isn’t necessarily wrong, auto-progression can be good for the experience, but it can affect how you interpret Path View percentages.
How to use this insight:
Treat scene completion as “the user reached the next scene,” not always “the user engaged.”
