Block Editor Tracking: Add pattern_category property to wpcom_pattern_inserted event

[david-szabo97]

Changes proposed in this Pull Request

• Add pattern_category property to wpcom_pattern_inserted event
• Add E2E test
  • Had to increase E2E events queue size. Inserting patterns fire a lot of block insertion events so this was necessary.
  • Also had to dismiss notices in some cases to avoid overlapping elements.

Testing instructions

• Follow steps to enable tracking debugging at PCYsg-nrf-p2
• Open Post Editor, and insert a pattern from the inserter sidebar. Make sure wpcom_pattern_inserted is fired and includes a pattern_category which is equal to the selected pattern category.
• Now insert a pattern from the quick inserter. Make sure wpcom_pattern_inserted is fired and and pattern_category doesn't exist..

Related to #53410

[matticbot]

Link to Calypso live: https://calypso.live?image=registry.a8c.com/calypso/app:build-9134
Link to Jetpack Cloud live: https://calypso.live?image=registry.a8c.com/calypso/app:build-9134&env=jetpack

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[Addison-Stavlo]

These questions are mainly for @ianstewart and @kurt213 regarding how we would want this to work.

Open Post Editor, and insert a pattern from the inserter sidebar. Make sure wpcom_pattern_inserted is fired and includes a pattern_category which is equal to the selected pattern category.

A pattern may have multiple categories, so I think either we need to:

• track whichever category is selected (as is done here)
  OR
• track the list of categories the pattern corresponds to?

However, when we select from the quick inserter where there are no categories to select.

Now insert a pattern from the quick inserter. Make sure wpcom_pattern_inserted is fired and includes a pattern_category which is equal to the first category of the pattern.

I would think instead of this we should either:

• Populate the field as undefined since no category can be selected. (If we are going with the first option above)
  OR
• once again track the list of categories the pattern corresponds to?

[ianstewart]

track whichever category is selected (as is done here)
Populate the field as undefined since no category can be selected. (If we are going with the first option above)

This seems like it would be useful. cc @kurt213

[Copons]

@david-szabo97 I think we can move ahead with the approaches confirmed by @ianstewart:

• Insert pattern from the sidebar inserter.
  • Track the selected category.
• Insert pattern from the quick inserter.
  • pattern_category: undefined.
    We should then clarify this in the event's property description in Tracks to make sure the undefined value is analyzed appropriately.

[kurt213]

Insert pattern from the sidebar inserter.
Track the selected category.
Insert pattern from the quick inserter.
pattern_category: undefined.
We should then clarify this in the event's property description in Tracks to make sure the undefined value is analyzed appropriately.

This sounds great and this logic makes the most sense to me for understanding a user's 'intent'.

[matticbot]

This PR modifies the release build for wpcom-block-editor

To test your changes on WordPress.com, run install-plugin.sh wpcom-block-editor add/tracking-pattern-insertion-pattern-category-name on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-l4k-p2

[Addison-Stavlo]

Now insert a pattern from the quick inserter. Make sure wpcom_pattern_inserted is fired and and pattern_category doesn't exist..

Im not seeing this at all. In both post editor and site editor inserting a pattern from the quick inserter doesn't seem to track any pattern_inserted event (on this PR or on trunk). Maybe I am missing something? 🤔

[david-szabo97]

Now insert a pattern from the quick inserter. Make sure wpcom_pattern_inserted is fired and and pattern_category doesn't exist..

Im not seeing this at all. In both post editor and site editor inserting a pattern from the quick inserter doesn't seem to track any pattern_inserted event (on this PR or on trunk). Maybe I am missing something? 🤔

🤔 Looks like quick inserter isn't using an object as metadata:

Look how the pattern name is just a string in the array. Whereas inserting patterns from the inserter sidebar:

Is using an object with a patternName property, and this is what we use.

[david-szabo97]

Quick Inserter's source code:

https://github.com/WordPress/gutenberg/blob/d312574cc0481b086539d077fbc5a9a6aa5e1959/packages/block-editor/src/components/inserter/search-results.js#L59-L62

which leads to

https://github.com/WordPress/gutenberg/blob/98a51d7efe5bbe06184f01c78d10f3c8f4f4e712/packages/block-editor/src/components/inserter/hooks/use-patterns-state.js#L43-L47

Compared to the block inserter sidebar:

https://github.com/WordPress/gutenberg/blob/19296105ec627729060d96e3a5427a174d97120a/packages/block-editor/src/components/inserter/menu.js#L74-L81

This looks like something we should fix in Gutenberg too. These shouldn't differ in my opinion. Although we still need to support this implementation in the tracking code. I'll come up with something.

[matticbot]

This PR modifies the release build for editing-toolkit

To test your changes on WordPress.com, run install-plugin.sh editing-toolkit add/tracking-pattern-insertion-pattern-category-name on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-mMA-p2

[Addison-Stavlo]

Maybe this is part of the issue I was noticing before - but Im running into another oddity 😅 .

It seems that whether we are using the sidebar or the quick inserter, it may fire wpcom_block_inserted or wpcom_block_picker_block_inserted depending whether or not a block was selected (that is, it used insertBlocks vs. replaceBlocks.

In the case of inserting patterns via the sidebar, it seems we are getting the wpcom_pattern_inserted event in both cases! 🥳

However, with the quick inserter it seems that we are only getting the wpcom_pattern_inserted event to fire in the insertBlocks case. So when the quick inserter is used from inside the context of an empty paragraph block it doesn't seem to be firing the wpcom_pattern_inserted event. 🤔

[david-szabo97]

Ughhh!

The pattern name is on a different index so the actionData[4] failed there.

Replaced with a more robust logic.

[matticbot]

This PR modifies the release build for notifications

To test your changes on WordPress.com, run install-plugin.sh notifications add/tracking-pattern-insertion-pattern-category-name on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-elI-p2

[Addison-Stavlo]

This is all working as expected now 😁

[WunderBart]

Just one comment!

[WunderBart]

Looks good from the E2E perspective, thanks! 🚀