Hey all,
I’m trying to replicate a marketing strategy matrix (that I used to use in Google Sheets) in Coda.
The reason I want it in Coda is so that I can connect every piece of marketing (whether blogs, social media content, marketing emails, videos, sales assets, lead magnets, landing pages, etc.) TO my marketing strategy matrix. I can’t do that in a spreadsheet, but - in theory – it should be doable in Coda.
This is what I have so far, but it’s leaving me with 330 rows PER TARGET BUYER PERSONA 
. That’s going to bog down my doc, for sure.
Is there a better way that I’m not seeing??
Question: why are you bothered by the fact that there are 330 rows?
Seems to me like that is what you need. What you could do to make it more “digestible”, is to create a view for, say, each target.
And that is where Coda shines: if you want to change your “dimensions” around you can easily do so. But that is only going to work if you have those 330 rows.
In my experience, tables with +500 rows end up bogging down the doc quite a bit, which is why I’m trying to figure out a way that won’t add so much weight to the doc.
500 rows should be a breeze.
How complex are your rows?
I have a doc with a thousand or so rows, but HEAVILY cross-referenced, with sub-items and recursive use of canvas columns. It takes 10 seconds or so to load first thing, but after that it is quick.
A few times I have loaded tens of thousands of rows to analyse. Again initial load takes a few seconds, after that it is fine.
Coda will start with the data that is necessary for the page you are on, so one of the first things to do is to see if you can break the data into smaller subsets, either views or using filters.
Try that and see whether it helps?
Hey @Piet_Strydom ,
I understand that the way I have it now works, but what I’m asking is if anyone in the community sees a better way of doing it than what I’ve built so far. I don’t like my docs to be overly complex, so before I go down this complicated route as my template for all current and future clients, I want to tap the community’s collective brain power since I know there are much, much smarter people than me in this room with a lot more Coda experience than I have.
How many ‘Target buyer personas’ are you expecting to have?
Can you maybe try to condensate your video to max 1-2 min? We don’t need to know every detail, but a 11-minutes video is quite a high time investment for anyone trying to help here.
1 Like
Hi Rai,
The structure you have now is the way I would do it. It is the most flexible.
The next step would be to address performance of any issues so arrive. What I would do next is to make a copy of the doc, and bulk it up with mock data, just simple copy and paste of representative data.
Create views to represent customers/ logical units of data.
This is the simplest, most flexible way in my way of doing things. Hopefully somebody else will bring their perspective.
If you still have performance issues, you can try creating docs with subs pages for each customer, or cross-docs. For no particular reason I always use the former.
Next level up would be to use a pack to store the data in a high performance database.
Regards
Piet
1 Like
What you did with the 330 rows is entirely correct in Coda. Unlike the spreadsheets, you stop caring about how the cells are laid out and start thinking about what each cell represents (i.e. an input that corresponds to an intersection of values from one dimension (stage) and another dimension (paradigms and identifiers; those aren’t separate dimensions but a hierarchy on a single common dimension). And to create these rows for another role, one would normally create a button that would populate all the necessary rows for all combinations of phase and identifier for that role.
A lot depends on the efficiency of formulas. In your case there are none, so even tens of thousands of rows collectively should not be a problem. I have docs with hundreds of thousands of rows that do run formulas, but I made them super optimized, so the doc was running totally fine even on my previous old PC.
That said, there are, of course, ways to implement this differently — from simply embedding the google sheet and then getting its data into Coda through the Sheets pack or some other mechanism, to using canvases and grids (simple tables) and hacky methods to extract information from those grids. It all depends on priorities. Maybe you don’t need to use the data from that table at all but you’d love to retain this grid-like layout to be able to visually compare adjacent cells — in a case like that it could just as well be a Sheets embed, no need to bring it into Coda.
3 Likes