►
From YouTube: Community Engineering Hangouts. Feb 24, 2021
Description
Agenda:
- Intelligent Merchandising - Visual Recommendations.
- Intelligent Merchandising - Iterative enhancements.
- Extended API coverage. Magento 2.5
A
B
Hey
everyone:
my
name
is
misha
kotov,
I'm
a
product
manager
at
adobe
today,
I'll
be
talking
about
our
our
one
prime
example
of
intelligent
merchandising,
which
is
our
product
recommendations,
feature
and
I'll
cover.
Some
of
the
things
that
we've
been
working
on
and
the
improvements
that
we've
been
rolling
out
and,
at
the
end,
want
to
focus
a
little
bit
on
future
looking
strategy,
yeah
even
maybe
get
some
feedback
from
from
those
that
are
on
the
call
about
you
know
which
directions
maybe
they
would
like
to.
B
I
would
like
us
to
move
to
next,
so
the
first
thing
that
I
wanted
to
cover
is
a
quick
summary
of
like
super
high
level
design
of
our
feature,
because
it's
it's
a
little
bit
different
from
the.
How
features
have
been
built
historically
in
magento,
so
hopefully
you
guys
can
see
my
screen
with
the
architectural
overview.
This
is
just
straight
on
our
dev
docs
page
about
recommendations.
B
So
two
things
that
I
want
to
cover
really
fast.
Is
that
there's
a
there's
a
magento
instance
here
on
the
left
and
then
there's
sas
services
over
here
on
the
right,
which
this
feature
is
the
first
feature
to
be
deployed
as
a
sas
service,
so
it
works
a
little
bit
differently,
but
the
two
main
things
that
I
want
to
cover
are
recommendations.
Product
recommendations
are,
they
need
two
sources
of
data
to
work.
One
is
a
catalog
sync,
so
this
is.
B
This
is
a
process
that
continuously
syncs
product
data
and
the
reason
you
need
that
is
so
that
recommendations
can
show
accurately
updated
product
names
or
pricing
and
reflect
current
availability
as
well
and
the
second
type
of
item.
Second
type
of
data
is
storefront
event,
so
these
are
collected
on
your
magento
storefront
and
it
kind
of
tracks
all
the
product
interactions.
B
Product
they
look
at,
they
add
to
cart,
they
purchase,
etc.
This
is
all
collected
at
scale
and
then
analyzed
by
adobe
sensei
to
create
these
associations
that
recommendations
then
are
built
on.
So
with
these
two
things
in
mind,
I
want
to
kind
of
jump
over
to
some
of
the
things
that
we
released
recently.
So
one
one
issue
with
this
catalog
sync
process.
B
B
Second
thing
you
see
here
is
total
products
synced.
So
I
have
you
know:
2048
total
products.
This
is
just
the
sample
data
catalog,
and
you
can
see
that
100
of
my
catalog
has
been
synced
to
to
our
sas
endpoint
and
again.
This
is,
you
know,
demonstrating
this
process
right
here,
taking
data
from
magento
backend
and
syncing
it
into
adobe
sense.
So
the
data
reflected
on
this
dashboard
is
what
ends
up
in
our
sas
services,
and
you
can
see
this
is
a
this
is
a
table
with.
B
I
think
it's
got
infinite
scroll
even
with
products
that
are
that
that
are
that
have
been
synced
and
you
one
thing
you
can
do
here
is
search
for
an
item
and
then,
once
you
get
search
results,
you
can
actually
open
some
of
these
details
and
kind
of
spot
check
that
the
the
product
data
that
was
synced
corresponds
to
what
the
changes
that
you've
made.
So
it
allows.
B
B
B
The
second
feature
that
we
released
somewhat
recently
is
is
called
inclusion,
exclusion
filters
so
I'll,
navigate
to
my
recommendations,
dashboard
to
show
you
that
this
is
just.
This
is
just
a
test
bed
here.
So
we
we
have.
We
have
some
data
that
hasn't
been
used
a
whole
lot
lately
so
anyway,
the
feature
that
we
that
we
released
as
you're
creating
a
recommendation.
B
So
this
is
divided
into
two
parts:
inclusion,
inclusion,
filters
and
exclusion
filters,
so
inclusion
filters
are
conditions
that
must
be
matched
in
order
for
a
product
to
be
eligible
for
recommendations
and
exclusions.
Any
products
that
match
filters
in
here
they
will
not
be
recommended
right.
So
a
prime
example
of
exclusions
is,
you
can,
for
example,
exclude
out
of
out
of
stock
products.
You
can
enable
the
filter,
and
then
you
can
say
I
want
to
exclude
these
out
of
stock
products
over
storefronts
same
with
low
stock.
B
Low
stock
is,
is
based
on
a
only
x
left
threshold
configuration.
I
think
we
added
the
tooltip
and
the
newer
version
of
this,
but
for
for
inclusions,
this
is
an
interesting,
interesting
scenario.
So
one
thing
you
can
do
is
filter
products
by
price.
You
can
say
you
know,
there's
a
threshold,
a
price
threshold
that
a
product
must
match
in
order
to
be
recommended.
B
So
you
can
you
know
you
can
enter
some
threshold
here
and
that
will
need
to
be
matched
by
all
products
that
will
show
up
in
recommendations
an
example
of
when
you
want
to
do
this
is
when
you
know
you,
you
have
deployed
a
recommendation,
your
storefronts,
but
you
you
get
a
lot
of
like
accessories
or
kind
of
like
low
margin
items,
low,
dollar
or
currency
amount
items
that
are
showing
up,
so
you
can
kind
of
filter
them
out
using
this.
Of
course
you
can.
B
Conversely,
you
can
create
an
exclusion
to
to
exclude
small
dollar
items.
There
are
also
kind
of
dynamic
rules
available.
If
you,
if
your
configuration,
is
set
up
in
such
a
way,
so
if,
if
you
say
that
you're
deploying
a
recommendation
to
a
product
detail
page
that
implies
that
a
shopper
will
be
on
a
product
detail
page
when
they
see
this
recommendation
and
you
can
drive
the
results
that
appear
there
off
of
the
attributes
of
the
product
being
viewed,
meaning.
B
I
can
say
that
the
category
of
the
results
of
the
recommended
results
must
match
the
category
of
the
product
being
viewed.
You
can
also
say
they
have
to
be.
You
know
mutually
exclusive
in
order
to
be
recommended,
or
you
can
just
simply
provide
a
static
list
of
categories
that
must
match
in
order
for
products
to
show
up
it's
again,
inversely,
it's
available
as
an
exclusion
rule.
You
can
say
you
know,
I
want
to
exclude
specific
categories
and
you
can
list
them
out
here.
You
can
say
you
know.
B
I
want
to
exclude
everything,
that's
on
my
sale
category
and
that
will
take
effect.
So
you
can
filter
by
category
price.
You
can
specify
even
specific
products
to
exclude
or
include
which
probably
won't
get
used
as
much,
but
we
already
went
to
over
out
of
stock
low
stock.
You
can
also
filter
based
on
product
type
and
and
configured
product
visibility.
So
these
are
you
know,
just
your
your
familiar
configurations
and
magento
admin
panel.
So
you
can,
you
can
include
or
exclude
products
based
on
their
product
type.
B
B
Let's
see,
let
me
let
me
wait
until
the
end
to
kind
of
to
to
take
questions.
The
the
I
have
one
more
thing
to
show
that
we
recently
released,
and
that
is
a
kind
of
a
new
type
of
type
of
ai,
that
we
added
a
new
recommendation
type
that
is
called
visual
similarity,
so
I
will
show
you
guys
that
this
is
covered
in
documentation,
navigate
to
our
recommendation
types,
and
this
is
a
new
one.
So
visual
similarity
is
a
recommendation
type
that
is
able
to
recommend.
B
Similarly
looking
products
to
what
a
customer
is
or
shopper
is
looking
at
on
the
site,
so
imagine
somebody's
looking
at,
I
don't
know
a
dress
and
they
see
similarly
looking
dresses
recommended
to
them.
So
this
is
kind
of
using
a
similar
technology
that
adobe
stock
is
based
on.
We
have
to
kind
of
mend
it
for
our
own
needs,
but
this
technology
is
able
to
pick
up
on
things
like
color
shape
size
like
even
texture
and
material.
B
B
Magento
stores
utilize
them,
but
for
you
know,
for
industries
like
fashion
or
apparel
or
retail
things
like
home,
furnishings
or
similar
industries.
This
will
this
could
be
very
useful
right,
but
because
it
doesn't
apply
to
everyone.
This
is
this
is
a
an
optional
add-on
to
our
recommendations,
so
it
says
here:
visual
similarity.
Recommendation
type
is
available
when
you
install
an
optional
module.
B
This
is
actually
similar
to
page
builder.
I
believe
page
builder.
Integration
for
product
rex
is
also
an
optional
module,
but
once
you
have
enabled
or
installed
that
module
I'll
show
you
how
to
how
to
deal
with
with
that
recommendation
type.
So
once
you
install
install
that
optional
module,
you
will
go
to
settings
and
you
will
want
to
toggle
this
flag
on.
You
can
say,
enable
visual
recommendations.
B
B
I
open
a
product
page
ignore
these
first
two
I
forgot
to
turn
those
off,
but
then
you
get
to
this
similar
styles
recommendation
unit,
and
you
can
see
that
you
know
these
are
similar
looking
items.
They
have
visual,
similar
visual
characteristics
to
what
what
item
I'm
looking
at
here,
you
know
this
is
the
demo
is
not
much
because
you
can
say
like
oh
well,
it's
just
picking
items
from
the
same
category,
but
this
is
actually
computer
vision.
Algorithms
running
behind
the
scenes.
A
B
Can
look
at
some
shorts
here
as
well
pick
one
out
and
as
I'm
looking
at
this
item,
I
get
recommended
similar
styles
to
again
to
what
I'm
looking
at.
So
this
is
this
is
it's?
It
works
pretty
well
so
far
we
are
constantly
looking
at
kind
of
iterating
on
these
relevancy
rankers,
and
so
this
will
get
better
with
time
as
we
kind
of
tune
them
in
and
train
the
models
on
on
more
and
more
ecommerce
data.
B
B
We
didn't
expect
much
adoption
then,
but
now,
at
the
beginning
of
the
year,
we're
looking
forward
to
more
adoption
and
more
use
cases
that
this
can
power,
so
that
was
that
was
the
overview
of
the
last
and
third
feature
that
went
with
ga
in
december.
I
want
to
cover
a
little
bit
of
where
we're
headed
or
things
that
are
in
progress
now.
B
One
thing
that
we're
working
on
is
it's
called
product
preview
for
recommendations,
so
this
is
this
is
an
ability
for
the
for
the
admin
user
as
they're,
creating
these
recommendations
as
they're
putting
them
together
to
be
able
to
preview
what
products
will
show
up
on
on
the
storefront
to
their
shoppers.
Apparently,
that's
not
very
easy.
Currently,
you
have
to
create
the
recommendation
and
go
to
your
storefront
and
then
see
like
what
kind
of
browse
around
and
see
what
kinds
of
things
are
showing
up.
B
But
now
we
and
I'll
show
you
previous,
is
on
our
one
of
our
test
environments,
but
now
you'll
be
able
to
write
in
the
admin
panel
to
see
what
what
is
getting
recommended.
So
I'm
going
to
the
same
form.
This
is
you
know
our
my
product
recommendation
creation
form.
You
can
see
that
right
away.
I
see
a
recommended
products,
preview
there's
and
it
displays.
B
However,
many
products
I
have
currently
selected.
So
some
of
these
options
default
to
value.
So
it
defaults
to
to
be
deployed
to
your
home
page
and
be
a
most
viewed
recommendation
type.
We
can.
We
can
change
this
around
a
little
bit
and
you
can
change
the
the
product
type
or
I'm
sorry,
page
type
and
the
recommendation
will
go
on,
but
with
some
of
these
you
will
need
user
input.
B
B
So
if
you
put
this
in
place,
then
voila
you
can
see
much
better
results
right
away,
because
you
know
we
now
say
show
me,
show
me
some
most
popular
products
by
product
views,
but
filtered
by
the
category
of
the
product
that
I'm
looking
at
so
now.
This
starts
to
make
much
more
sense
right
this.
These
are
women's
jackets
and
hoodies
and
etc.
B
B
This
is
a
very
valuable
thing
that
will
help
help
preview
and
and
kind
of
help
help
gain
confidence
that,
when
you're,
when
you're
deploying
the
storefront
actually
makes
sense
one
one
quick
thing,
quick
thing
to
mention
here:
if
you're
deploying
to
these
different
page
types
for
cart
and
order,
confirmation
you'll
be
able
to
enter
multiple
skus.
Just
so
like.
If
you're
deploying
a
recommendation
to
a
cart
page,
you
can
actually
simulate
a
cart,
so
you
can
say.
B
Let
me,
let's
assume
that
a
customer
has
a
couple
different
bags
in
their
cart
and
and
these
will
show
you
the
most
popular
products
and
then
again
with
the
filters
that
you
apply.
You
can
play
around
with
this,
but
this
this
will
allow
you
to
simulate
a
card
with
multiple
products
on
a
pdp.
Obviously
you
can
only
select
one
so
that
works
there.
B
The
so.
The
next
thing
that
I
want
to
talk
about
that's
in
flight
is
is
something
that
we've
gotten
a
ton
of
requests
about,
which
is
compatibility
of
this
product
recommendations
feature
with
with
headless
storefronts
or
pwa,
specifically,
so
the
I'll
go
back
to
my
diagram
here,
the
the
biggest
challenge
with
with
that-
and
it's
been
a
limitation
so
far,
because
recommendations
currently
are
supported
only
on
kind
of
magento
native
storefronts.
B
So
we
are
currently
working
on
pwa
support
for
this
feature
and
that's
effectively
it's
just
this.
It's
teaching
a
pwa
storefront
how
to
emit
these
events
when
customers,
when
shoppers
interact
with
different
products
on
storefront
so
and
we
actually
have
these
events
documented.
Not
not
all
these
are
required,
but
you
can
see
that
kind
of
the
example.
B
Examples
of
events
that
are
admitted
today
again,
not
all
of
these-
are
required
to
build
recommendation
models,
there's
a
handful
that
are
critical
so
we're
starting
with
those
and
we'll
kind
of
expand
from
there.
But
it
is
it's
a
progress,
we're
hoping
to
release
soon.
I
don't
have
a
commitment
at
this
time,
but
in
the
kind
of
hopefully
in
the
first
half
of
the
year,
and
then
we
will,
we
will
certainly
look
to
support
other
kind
of
implementations
of
storefronts.
You
know,
besides
pwa,
we
want
to
make
this
possible
on
any
custom.
B
B
A
B
Yeah
happy
to
hang
out
and
and
look
at
the
chat
one.
One
last
note
before
I
go
since
I
don't
see
any
questions
we're
starting
to
kind
of
evaluate
direction
of
where
to
go
next
with
with
intelligent
commerce
and
aiml
capabilities.
I
would
love
to
hear
the
community's
thoughts
on
this.
If
you
guys
have
used
cases
or
or
think
they're
they're
great
opportunities
for
us
to
tackle,
with
with
data
powered
technology,
I'd.
B
A
C
C
The
live
stores
during
upgrade
and
one
of
the
ways
to
mitigate
this
issue
is
to
reduce
the
so-called
gray
area
that
we
have
right
now
in
our
api
coverage
and
kind
of
legalize
apis
that
we
already
have
in
magento
but
the
ones
which
we're
not
treating
them
as
api
at
adobe.
So
if
you
look
at
this
picture,
you
can
see
that
let's
say
this
square
on
the
left
side.
C
It
represents
all
apis
or
like
all
classes
and
interfaces
in
magento,
and
we
treat
some
of
them
as
apis
and
we
check
for
backward
incompatible
changes
when
we
deliver
changes
to
magenta
core
for
these.
For
these
classes
and
interfaces,
then
there
is
another
section
at
the
bottom,
which
is
larger
one
which
nobody
treats
as
api
and
community
members
are
not
using
this
as
api,
and
there
is
layer
in
between
which
we
do
not
read
as
api,
but
community
members
have
to
use
them
for
some
reason.
C
Usually,
this
is
because
there
is
not
adequate.
There
is
no
adequate
coverage
in
specific
area
and
they
have
to
use
classes
which
are
not
marked
as
api,
and
our
goal
is
to
reduce
this
gray
area.
We
will
not
be
able
to
eliminate
it
completely.
We
understand
that,
but
at
least
we
will
be
able
to
reduce
this
area
significantly,
and
that
is
what
we
are
trying
to
achieve
in
scope
of
this
initiative
and
also
to
be
clear.
We
are
not
introducing
new
interfaces
on
new
classes.
C
So
they
can
still
be
broken
in
this
case,
and
another
benefit
would
be
for
community
developers,
obviously
because
they
will
not
have
to
depend
on
the
code,
which
is
not
officially
marked
as
api,
and
this
will
lead
to
kind
of
satisfaction
from
developers
perspective,
and
it
will
be
easier
for
them
to
maintain
and
refactor
the
code
and
keep
it
up
to
date.
With
latest
magento
releases.
C
C
C
We
manually
review
them
and
we
are
going
to
mark
about
100
of
those
as
api,
because
in
in
most
cases,
these
could
be
treated
as
layer.
Super
types
where
extensions
are
kind
of
required
to
use
them
to
to
be
able
to
inject
the
behavior
into
magenta,
or
they
could
be
classes
which
were
initially
intended
for
extension
and
magento.
Core
uses
them
to
extend
from
them
like
abstract
classes,
and
they
are
not
marked
as
api,
so
those
those
entities
they
will
be
marked
as
api.
C
C
It
is
prohibited
to
add
new
apis,
since
extension
cannot
be
compatible
with
both
patch
releases
if
they
have
different
apis.
So
that
was
kind
of
solution
many
years
ago
to
treat
all
blocked
apis.
And
now
we
are
saying
that
we
have
probably
a
better
better
option
and
instead
what
we
did.
We
went
through
all
blocks
and
we
are
going
to
mark
those
blocks
as
api
for
which
it
makes
sense.
C
Usually
these
blocks
introduce
new
functionality.
They
declare
new
public
methods
and
there
is
a
portion
of
blocks
which
are
either
not
referenced
from
any
layout.
So
those
will
be
skipped
and
we
probably
cannot
remove
them,
because
somebody
can
use
them
in
the
extensions,
but
at
least
we
are
going
to
mark
them
as
apis,
and
there
is
another
section
or
portion
of
blocks
which
are
not
providing
new
functionality.
C
C
I
mean
it
seems
like
not
a
big
deal,
but
it
will
be
helpful
to
clarify
the
boundary
between
api
and
api,
and
it
will
also
be
helpful
for
our
tools,
like
upgrade
compatibility
tool,
for
example,
because
we
will
not
have
to
implement
exception
exception
rules,
basically
for
treating
some
classes
differently,
like
treating
extension
attributes
as
api
all
the
time.
So
we
will
have
simpler
implementation
in
our
tools
and
the
rules
will
be
also
simplified
in
this.
C
Case
now,
let's
briefly
take
a
look
at
how
you
can
participate
in
this
initiative
and
I
will
go
to
pull
request
to
our
architecture
repository.
So
we
have
pull
request
here
and
in
this
pull
request,
we
have
about
1500
new
entries
as
api
candidates
like
there
is
pretty
huge
file
with
all
apis
that
we
suggest
and
that
we
are
planning
to
mark
as
apis,
and
if
you
have
time
you
can
go
and
check
that
out.
C
Additionally,
if
you
believe
that
you
know
some
cases
which
are
missing
in
current
api
coverage,
but
you
you
know
that
you
have
to
use
them
for
some
reason.
Please
leave
your
comments
in
this
pull
request
and
we
will
consider
all
additional
cases
which
are
not
currently
in
in
the
list
of
these
1500
api
candidates.