Add Pendo Track Events for Weave GitOps CLI

[JamWils]

As a user, I understand you are trying to build a product that helps me to get the job done and to do that effectively, data can be useful. Please keep my privacy in mind and only collect what you need. As an OSS user I want you to ask for my permission first before collecting information. As an enterprise user I understand that you will collect this by default, but I do want to have the ability to turn it off.

As a product manager, I want to understand the most common OSS and Enterprise CLI commands that are used by our users. It would be nice to know whether they are running the command from an OSS or Enterprise binary. It would be nice to know which version of the CLI they are running the command. It would be nice to be able to distinguish each user with a unique visitor ID.

Acceptance Criteria

3. We should have this stored in a place where there is no impact if they upgrade to a new version of the CLI. I.e. we do not have to keep asking them if we can collect info each release.
4. Each track event should have the following event properties "tier" which can be oss|enterprise and "version" which is the CLI version, and "app" which is "cli", as well as the command after gitops such as "add cluster" or "run".
5. We would like to know which flags they are using. Do not collect any information about the each flag's values they are using with each command, we just want the "key".

https://support.pendo.io/hc/en-us/articles/360032294291-Track-Events-Configuration#volume-0-5

Moved question to turn on to different ticket

[JamWils]

FYI: @davidstauffer, @sympatheticmoose, @MostafaMegahid, and @josefaworks

[opudrovs]

@ozamosi based on the following discussion (in the comments) we might need to edit the acceptance criteria and the format in which the tracked command path and flags data is submitted.

It should be easy to modify as soon as the updated criteria are provided.

[opudrovs]

@JamWils you've already updated the acceptance criteria, thank you!

Minor questions:

We would like to know which flags they are using and each flag should be their own track event. Do not collect any information about each flag's value, just a simple "true|false" so we know it was used.

So, for example, for the following command:

gitops beta run ./deploy/overlays/dev --timeout=3m --port-forward namespace=dev,resource=svc/backend,port=9898:9898

we should submit two track events:

{
    "event": "beta run",
    "properties": {
      "tier": ...,
      "version": ...,
        "flags": [{
        "timeout": true
         }]
    },
}

and

{
    "event": "beta run",
    "properties": {
      "tier": ...,
      "version": ...,
        "flags": [{
        "port-forward": true
         }]
    },
}

Correct?

Or should we also submit separate track events with the value false for each of the unused command flags ?

And does Pendo support arrays of objects as values?

Maybe we should use smth. like

{
    "event": "beta run",
    "properties": {
      "tier": ...,
      "version": ...,
      "timeout": true
    },
}

or

{
    "event": "beta run",
    "properties": {
      "tier": ...,
      "version": ...,
      "flags": ["timeout"]
    },
}

or

{
    "event": "beta run",
    "properties": {
      "tier": ...,
      "version": ...,
      "flag": "timeout"
    },
}

? Which format is preferred? Technically none of them is a problem.

[opudrovs]

Right now I am submitting all flags as a text string, so I just need to split it.

[JamWils]

Good question,

I think we want the "flags" as individual event properties with "true" and "false". This will allow us to use the data analytics features directly within Pendo. The fact that we are now making each command a unique track event means we will be able to keep the event property count pretty low as they will be unique for each command that is run.

So in the above examples, I think this is the one we need to use:

{
    "event": "beta run",
    "properties": {
      "tier": ...,
      "version": ...,
      "timeout": true,
      "port-forward": true,
    },
}

I don't think we need to do "false" for the other flags, it should default to that...I can test it when you get a PR up.

[opudrovs]

@JamWils sorry, one more question, there is a minor clash between:

I think we want the "flags" as individual event properties with "true" and "false".

and

I don't think we need to do "false" for the other flags

Here is the list of all GitOpsRun flags (and there may be some globel flags used with it I suppose):

type RunCommandFlags struct {
	FluxVersion     string
	AllowK8sContext []string
	Components      []string
	ComponentsExtra []string
	Timeout         time.Duration
	PortForward     string // port forward specifier, e.g. "port=8080:8080,resource=svc/app"
	RootDir         string

	// Dashboard
	DashboardPort           string
	DashboardHashedPassword string

	// Session
	SessionName         string
	SessionNamespace    string
	NoSession           bool
	SkipResourceCleanup bool
	NoBootstrap         bool

	// Global flags.
	Namespace  string
	KubeConfig string

	// Flags, created by genericclioptions.
	Context string
}

So, I am not adding keys to the event properties for flags which are not used? Thus, the tracked event for the command above will not have, for example, "session-name": false and "allow-k8s-context": false under properties?

[opudrovs]

Did you mean that each flag property should be a boolean value but that values with false value should not be submitted in the event props?

[opudrovs]

@JamWils I've updated the event properties, this is what I have right now for the following commands. Does it look right?

type, visitorId, and timestamp keys are required.

The event property names are sanitized according to the Pendo requirements (max length 32 and can contain only letters, numbers or underscores, cannot start with double underscores (have not sanitized flag names for this)), under Field Names: https://support.pendo.io/hc/en-us/articles/360032294291-Track-Events-Configuration#api-requirements-0-7

gitops beta run ./deploy/overlays/dev --timeout=3m --port-forward namespace=dev,resource=svc/backend,port=9898:9898

{
  "type": "track",
  "event": "beta run",
  "visitorId": "2fesk6Lqmi",
  "timestamp": 1669083507256,
  "properties": {
    "app": "cli",
    "port_forward": true,
    "tier": "oss",
    "timeout": true,
    "version": "v0.10.2-rc.1-89-g88508ae7"
  }
}

gitops create dashboard ww-gitops --password=123

{
  "type": "track",
  "event": "create dashboard",
  "visitorId": "2fesk6Lqmi",
  "timestamp": 1669084019661,
  "properties": {
    "app": "cli",
    "password": true,
    "tier": "oss",
    "version": "v0.10.2-rc.1-89-g88508ae7"
  }
}

[opudrovs]

There is a potential issue that a sanitized flag name could be the same as a hardcoded property key (app, tier, version).

What should I do about it?

[opudrovs]

It's tracking the new events, hurrah!

[opudrovs]

Added a flag_ prefix to flags (based on @ozamosi 's suggestion), to avoid the conflict between flag names and names of hardcoded event properties. So, now the data tracked looks like:

{
  "type": "track",
  "event": "create dashboard",
  "visitorId": "hlHdSMskQE",
  "timestamp": 1669129788574,
  "properties": {
    "app": "cli",
    "flag_password": true,
    "tier": "oss",
    "version": "v0.10.2-rc.1-91-g292e65b8"
  }
}

{
  "type": "track",
  "event": "beta run",
  "visitorId": "hlHdSMskQE",
  "timestamp": 1669130064995,
  "properties": {
    "app": "cli",
    "flag_port_forward": true,
    "flag_timeout": true,
    "tier": "oss",
    "version": "v0.10.2-rc.1-91-g292e65b8"
  }
}

And each event property name with the prefix cannot be longer than 32 characters, according to the Pendo event properties specs.