Skip to content

bug: Naming convention of network/integration/channel #181

Description

@ddxv

I believe all three network vs integration vs channel will end up referring to the same entity type. This is used on several places including:

postback-api endpoints and documentation
analytics-db for table and column names
dash-backend for endpoint names, variables etc
dash-frontend the final user facing dash also uses various terms

These should be condensed for an MVP into a single name.

Pro / Cons:

  1. Networks - Most specific and easiest to understand, but it's specificity means it might be confusing with the larger concept such as custom_networks (ie user created links to share, which will need to choose a 'network' name, which at that point doesn't make as much sense since the user's email campaign or social share is not a 'network' per se. network also can overlap with backend/code reserved words like in PostgreSQL causing need to do SELECT my."network" from mytable my
  2. Integrations - Clearly states the use case on dash-frontend for setup of ad networks' settings. Is vague enough that it somewhat includes share links. Definitely does not work well on backend links, database etc where it becomes unclear what it is referring to.
  3. Channels - Ah, the classic vague name. Useful for links/backend/code where it feels vague enough to cover all use cases but specific enough to not overlap with other terms. Least useful for front end where new users may not be clear that "Channels" refers to their ad networks and social share links? Always makes me think of TV channels.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions