potential generalized modeling of campaigns, content, etc.

[jesteria]

Thinking this is a way we could generalize our existing idea of a campaign, for reporting purposes in particular. Our campaigns deliver traffic to clients' content via some number of vehicles. A piece of content might be a donation page – whatever the client wants supporters to take action on. A vehicle might be an email, a Facebook post, a simple Facebook notification or a Targeted Sharing campaign. The Uniform Resource Name, ContentVehicleCampaign.urn, identifies the particular vehicle used, via a Targeted Sharing slug, a Facebook post slug (the ID), or whatever ID we want to give to notification sends.

Events can then be tied to a campaign, which has extended properties as needed, (e.g. in a Targeted Sharing-specific table, much like the existing campaign_properties). content_vehicle_campaigns tells us what kind of campaign the client requested, what sort of events to look for, and which app-specific tables to look in or insights to check (if applicable).

Not extremely confident that this makes sense, but it seems a lot closer to a useful model for this new stuff than we had before.

[thcrock]

Makes sense from a data integrity/simplicity perspective, but an accessor for client directly from campaign would be nice.

[thcrock]

Looks pretty good. I'm interested in how we're going to link campaigns together in the end; for instance, if a targeted sharing campaign is pointing at a FB post, we probably want to know about it (ie a target_urn in the targeted_sharing-specific table). That will be something to worry about when we create those vehicle-specific tables.

[jesteria]

Yeah, I didn't want to overdo it, there – I can imagine we might not need to know exactly how they linked to each other, (or, yes, at least not need to record it here). Regardless, we can see about that, as soon as the need presents itself.

@snyderchris's advocation for the devil asked, to paraphrase, "do we need a campaign at all? Why not just hang posts, or whathaveyou, from client_content, without additional structure?" I think, though, that we're satisfied that it is useful to record which products the client used, (posts, notifications, etc.), and to group them, in the background, into a campaign. We probably won't report by campaign, at least not explicitly, but quite possibly implicitly – "this many people responded to this round of notifications, then this many of those people clicked the link in the post", etc. And, regardless, my instinct is that we will want this sort of structure for our own analysis. I'm still not highly confident that this is the model that will serve us, but it seems like a reasonable base, without getting far into things we really haven't built yet.

[jesteria]

OK, @thcrock, @snyderchris and @mattratt – I removed the troubled campaigns table and the questionable vehicle_owners table; and, I beefed up the content_vehicles table a bit, such that it can now specify the "intermediate" content vehicle to which it links, (rather than linking directly to the client's content).

Thinking this might do the trick to record what's going on with our current offering. If we find we need more, or less, we can make the change, then. But, let me know if you see anything unreasonable, now.

As for the denormalization which allows a content vehicle to incorrectly point to an intermediate serving different client content, I could make the vehicle's relationship to its "target" polymorphic – it would then only point to one "thing", either the other vehicle or the actual client content. The relationships would be discerned by following the chains, or I imagine through more sophisticated JOINs. However, this would make a number of database interactions harder. (For example, you wouldn't be able to as easily see that a notification, regardless of that it points to a post, was created for the two objects' shared purpose of driving traffic to the client content of that post.) You'd also lose a good bit of protections / constraints, since the nature of the relationship between vehicle and target would be managed entirely outside the database. This is a possibility, though, and the more I think about it, the more doable it sounds.

If it helps, here's a Gist of the actual SQL statements that these classes generate. (It's not precisely right, because I was able, in the included migration, to reorder columns a bit; but, that's a nonfunctional discrepancy. I can also run this through a schema mapper at some point, if that's desired.)

[thcrock]

url/client makes sense, but name/client I'm not as sure about. Is the name a display name/chosen by the user? If so, what happens if they use the same name as an existing ClientContent? This might not be a concern, but I'm unsure how the name field will be used.

[thcrock]

The handling of intermediate vehicles looks good for now; I think using the client content as the linking field is a good idea. I did want to make sure that the urn in ContentVehicle was indexed, and it looks like you took care of it with the unique_together rule.

Overall, this looks good and once you answer my question in the note above, you should along with the other two. I was looking at the final output SQL you attached here and consider that my review of all three requests.