[MUSIC PLAYING]
HOI LAM: So on my
side we have Ninu,
who's a part manager on
the Google Beacon platform
and also Ani who's a part
manager on the physical web.
So you have basically all of
the Google Beacon platform
represented on this stage.
So we can kind of jump
through sort of questions.
Actually I left my list of
internet requests on here.
So what we do is I'll kick
off with two questions,
and then afterwards, if
anyone in the audience
want to ask a question, please
feel free to put your hand up
and we'll go from there.
NIRDHAR KHAZANIE: Sounds good.
Yeah.
HOI LAM: OK so the first
question is why is Google
creating a Beacon platform?
I mean there are
platforms already.
So--
NIRDHAR KHAZANIE: Sure.
HOI LAM: What do you think?
NIRDHAR KHAZANIE: So
first off, hi guys.
My name is Nirdhar Khazanie.
I'm Ninu.
I'm product manager
here at Google.
Really happy to be here
with Ani, and with you, Hoi.
So kind of like why we
designed the Google Beacon
platform and Eddystone.
So think about it like this,
so the Google Beacon platform
spans everything
that you might want
to do with the very high
quality context precise signal
that you might get
directly from a Beacon.
Let's try to break this down
into three main components.
The first one is Eddystone.
So Eddystone is our
open Beacon format.
Then the second part is the
actual scanning libraries
that we have, which
are platform agnostic.
And the third part is the actual
Google Beacon registry itself.
So let's talk about Eddystone.
So Eddystone is our open
frame specification format.
So we released this last
year in July of 2015.
So it's open, meaning that
it's available on GitHub.
Today you can download
it and actually works
on both Android
as well as an iOS.
It's extensible, so we have
three mainframe formats today.
So there's Eddystone UID.
There's Eddystone URL, which
works with the physical web,
which is what Ani works on.
As well as there's the Eddystone
TLM, which is telemetry data.
And something that
really, I think,
that differentiates us from some
of the other different Beacon
formats which might be out there
is that, with telemetry, we
have the ability to work
directly with the Proximity
Beacon API where
you can actually
get health stats and battery
stats, et cetera, directly
on your Beacon
deployments that you might
have out there in the world.
So the second part
is with scanning.
So our nearby
API's, actually it's
a platform scanning API that
works, again, cross-platform,
both on Android
as well as on iOS.
And with the nearby,
some of the benefits
that you get
underneath the hood are
that you get over the
air updates that actually
help with performance as well
as with battery improvements.
Further, you also can ask for
a limited set of permissions,
which actually works really
well across both platforms.
And then, also this
helps to include
things like pending intents,
as well as background
subscriptions that we have.
Though this
basically leads into,
with the nearby API connecting,
directly through the Proximity
Beacon API, and then onwards
to our Google Beacon platform,
which is like our
back end services.
And so with that, you can
actually add any attachments
that you might have
from your Beacons
that you will have
registered with Google.
And then from there
you can add content
that you want to be able to
deploy out within your apps.
And so this kind of
like end to end story
is what we're really
looking forward to.
And that's kind of
what we're really
looking at the developers
in the audience
to be able to also work
with us afterwards.
So if you have any
questions about this,
we'd love to be able to
hear them and see how we can
get your apps working better.
HOI LAM: Cool.
Another question is there
are other geolocation
techniques like GPS and wi-fi.
Why should people
think about Beacons?
ANIRUDH MOHAN: Yeah,
we think Beacons
are valuable for
two main reasons,
separate from other
localization technologies.
The first is that it works
really well, particularly
in indoor environments.
We spend most of
our time indoors,
but the existing localization
technologies that are out there
don't do a great job of
being able to figure out
exactly where a user is inside.
Beacons provide pretty
scoped and pretty short
range cues as to
where a user might
be in an indoor environment,
so it works well there.
The second is that Beacons
work very well for establishing
context as to where a user is
relative to their location,
not necessarily precisely the
coordinates that they're at.
So for example,
Beacons do a good job
of figuring out whether or not a
particular individual is inside
of a room or outside
of a room, which
is valuable context that certain
applications can take advantage
of.
So these are two
ways that Beacons
are a little different
from other localizations
technologies.
HOI LAM: Cool, are there
any live questions?
If not, I will ask
some of the questions
that I've actually
got from the internet.
So you can actually see these
on my G+ and twitter account.
So the first question
is, how many of my users
will be able to use Beacons?
What android, iOS,
and chrome versions
do we need for the
users to use it?
NIRDHAR KHAZANIE:
Sure, so I know
that we've been
actually supporting
Bluetooth low energy.
So just to give you guys
a little bit of context,
so Beacons actually work
on Bluetooth low energy.
Right, so I'm going to
refer to that as BLE.
So we've actually had support
for a BLE in android since 4.3,
which is Jelly Bean MR2.
And so that population, if you
look at it from then till now,
so we have 1.4 billion Android
devices which are there
in the public
today, and about 73%
of all those different
devices are actually
capable of working
directly with BLE.
And so, from the iOS side,
so let's see, so in iOS ,
if you have an
iPhone 4s or above,
and then also an iPad third
generation or earlier,
or later, it can actually
work directly with Beacons.
HOI LAM: Cool, physical web?
ANIRUDH MOHAN: Yeah,
so specifically
for the physical web,
and Google chrome support
of the physical web,
we are supported
on an iOS as of Chrome 45,
which launched in mid July.
So if you're on the latest
version of Chrome on an iPhone,
you'd be able to use it.
On Android, we're coming soon.
But hopefully by the
end of the quarter,
be able to start using it there.
HOI LAM: That's a great
cross platform stories.
I launch on iOS first.
[LAUGHTER]
We've got a live question.
AUDIENCE: What about desktop?
HOI LAM: What about desktop?
ANIRUDH MOHAN: Specifically
for the physical web?
AUDIENCE: Yeah.
ANIRUDH MOHAN: We're very
focused on the mobile use case,
in particular.
We think that's where
Beacons make a lot of sense.
As users sort of interact
with the physical world,
and can discover URLs
in various locations,
so we're prioritizing
mobile for now.
In the future, it
might make sense for us
to evolve in the desktop,
but it's currently not
in our plans.
HOI LAM: All right, another
question from the internet
is, this particular
developer is considering
using Beacons for
positioning, so just
kind of deploy a
whole bunch of Beacons
and do very precise
positioning within a room.
What do you think about that?
ANIRUDH MOHAN: So
as I mentioned when
describing sort of where Beacons
are particularly valuable,
one of the points
I was talking about
was how it provides
very good context
as to where a user might be.
And this is sort of
the use case that we
like to encourage with
a Beacon deployment.
Because of the way that you
can track where a user is
from a Beacon using
RSSI values that
are very variable in different
indoor locations based
on the material of
the environment,
based on how many individuals
are inside the room,
we don't think Beacons are
a very great technology
for figuring out precisely
the coordinates of a user
in a location, but
where it is useful
is figuring out
whether or not a user
is within a certain region.
So we tend to encourage
context based applications
rather than localization
based applications.
NIRDHAR KHAZANIE: Some
of the other things
I think that we can also
do is using like the places
API, which is there.
So that allows you to
have a level of context
of like what is the
lat what is the long,
and then also are
you indoors, or are
you in a particular region.
So that helps to also provide
a little bit better precision.
HOI LAM: Cool.
And other questions
that we get is,
because we do have multiple
frame types within Eddystone,
what's the best practice
in terms of combining
those different types?
NIRDHAR KHAZANIE: Sure,
so I'll take that one.
So we currently have three
different frame formats, right?
So there's UID, URL, and TLM.
So with TLM, specifically
with telemetry, this kind of
gives us a little bit more
of that differentiator.
And so we actually
recommend and we actually
encourage you to be able to
have the Eddystone UID as well
as TLM frame, and then being
able to actually transmit those
together in parallel.
For something else, also
like with telemetry,
the benefit is, if you are in,
let's say, a very local region,
one that may be a
little bit more remote,
you might want to actually
broadcast your TLM
packet a little bit
more frequently as well,
so it's able to be
picked up easier.
ANIRUDH MOHAN: We
call the process
of concurrent broadcasting
sort of interleaving.
And one of the nice things
is, if configured properly,
interleaving actually does
not hurt the performance
of the Beacon deployment.
It's very minimal in terms
of its power consumption.
So it's a great way of
sort of broadcasting
all the different frame
types that a deployer might
want to without
sacrificing performance.
HOI LAM: Live question.
AUDIENCE: So
yesterday, some of us
saw the Project Tango demo,
which was really amazing.
And I was kind of could
we pair that with Beacon
somehow to really help people
who have vision impairment be
able to navigate room,
be able to figure out
where something is in a room.
NIRDHAR KHAZANIE: Sure.
Yeah, go ahead.
HOI LAM: Let me just
repeat that question.
So yesterday we saw the
demo from Project Tango.
What are different ways and we
can combine that with Beacon
to enable people that might
have visual impairment,
in this case, to help
them navigate around?
NIRDHAR KHAZANIE:
You want to jump in?
ANIRUDH MOHAN: I was going to
let you talk about wayfinder.
NIRDHAR KHAZANIE:
Sure, no problem.
Yeah, so let me talk about
wayfinder for like a minute.
So wayfinder is an
open standard that
google.org, which is like our
philanthropic arm at Google,
they actually gave
them $1 million.
So this happened in December.
And so the concept
is, in London,
if you're going through the
Tube, if you're going between,
let's say, the Piccadilly line
to, let's say, somewhere else.
For people like us who have
the ability to be able to see,
it's really easy, right?
It's much easier
than for someone
who's visually impaired.
But what we're actually
looking at and actually doing
is seeing how can
you get from point A
to point B if you're
visually impaired,
and can Beacons actually help
guide that experience and make
that possible, right?
So will it actually say, OK go
down this particular tunnel,
take a right, go up the
stairs, and so on and so forth.
And so those are the kind of
things that we're actually
looking into, and seeing how we
can actually help accessibility
based features, and try
to move those forward
as well in the stack.
I think it's a really
interesting idea with Project
Tango.
And it's not something that
we've actually looked at today,
but it gives us some
ideas on where we actually
could move forward.
So thank you for
that recommendation.
ANIRUDH MOHAN:
We're also chatting
with folks at the
Beacon office hours
earlier today about
other potential sort
of Tango-Beacon integrations.
And someone brought up the
really interesting idea
of using a Tango mapped spatial
location to sort of queue
what ideal deployments
could look like in a room.
For example, if you were able
to map a room with Tango,
could you then use
that information
to figure out where
you could optimally
place Beacons to cover the
entire environment, sort
of what sort of signal
strength that you
need to put those Beacons at
in order to blanket the room.
So there's other sort of
applications with Tango
too that we haven't
looked into yet,
but certainly I think
the door is open.
NIRDHAR KHAZANIE: Think
we have a question.
HOI LAM: Over there.
AUDIENCE: Does the rest of
the platform [INAUDIBLE]?
HOI LAM: So the question there
is, does the proximity Beacon
API or nearby work with
other types of Beacons
that are not Eddystone?
NIRDHAR KHAZANIE:
Yeah, so we're actually
focused right now on Eddystone.
Primarily because
that is what we're
doubling down our efforts on.
So I think a lot of
our time and effort
is going to be focused on
Eddystone in the next upcoming
months and year.
And we think that, by
keeping it open and kind
of like that concept on GitHub
where anyone can actually
commit to it and we can
make the platform better,
that's our vision
for how we're going
to be able to scale our
efforts moving forward.
HOI LAM: Yeah and
just add to that, I
think with the proximity
Beacon API you can
register a lot of Beacon types.
But as we said earlier,
with Eddystone, you
get the telemetry frame and
you get the URL frame we're
hoping that developers will look
at that and say, wow you know,
all that extra functionality
is really useful to me.
And as a result, they would
choose Eddystone maybe even
on it's own merits
on that front.
ANIRUDH MOHAN: The
only thing I would add
is that, for a given
Beacon deployment,
Eddystone isn't mutually
exclusive with a different type
of sort of Beacon format.
So developers can,
on the same Beacon,
deploy multiple different
types of formats.
AUDIENCE: I guess my
question is more [INAUDIBLE]?
HOI LAM: Yeah, so
the sort of context
there was, for existing
deployed to Beacon already,
can they utilize some
of the cloud service.
So the answer is yes, you
can register those Beacons
with the proximity Beacon API.
OK, anything else?
Well, I'll go down the list.
So there is also
another question about,
because we have 18
partners already,
many producing multiple
models of Beacon,
is there an easy way to
kind of look at the specs
and what differences
would there be
from choosing kind of one
manufacturer over another one?
NIRDHAR KHAZANIE: Yeah I think,
so the concept is this, right?
So because Eddystone is so
open, we have 18 partners today.
So if you go to g.co/Beacons,
you can actually take a look
at all the different
partners which are there.
And I think the benefit,
and kind of like the reason
why we even have
this open platform,
is so we have multiple different
OEM's that can actually
work with us as Google.
And then each and every
single different partner
has their own strengths, right?
And so they have
different services
that you all can
choose from, and that's
kind of like the benefits
of actually using
Eddystone in general.
We are working very strongly
with all the different OEM's
to make provisioning easier, as
well as registration directly
through our
Proximity Beacon API,
and then also directly with our
back end, with our services.
So the Google Beacon platform
is very much so focused
on seeing how we can get a
lot easier for developers
to start using it
from the ground up.
And so look for that in
the next upcoming quarters.
ANIRUDH MOHAN: And
it's important to note
that, when we say partners,
we don't necessarily
mean that these
are the vendors who
we encourage developers to use.
These are just
ones that have met
the proper sort of Eddystone
certification process, that
are faithfully reproducing the
spec that we have on GitHub.
Beyond that, as Ninu
mentioned, they all
have different points
of differentiation,
and it's up to the
individual developer
to decide which one
they'd like to use.
HOI LAM: And just to
add to that answer,
another thing is, the
strength of those 18
partners and the
ecosystem that we have is,
depending on your
use case, you might
want to choose different
types of Beacon.
So you know, if you have
a mains power readily
available within the room
that you want to deploy,
you might just want to plug
a Beacon into that socket.
And as a result, you don't
need to worry about replacing
or the battery power at all.
Or alternatively,
if you're thinking
about really possible use
case, and you want the smallest
possible Beacon, we
also have some partners
that produce kind of coin
sized Beacons as well.
So you can choose
kind of whatever that
suits your particular use case.
Anything?
Nope, cool.
So, going down.
So for the physical web, what
would the experience be like?
I guess it's for the
people that was not
in Scott's presentation.
And I've got a slide
that might help.
Ani--
ANIRUDH MOHAN: Sure.
HOI LAM: You run through that.
ANIRUDH MOHAN: So
some of you folks who
were in the room for a
Scott Jenson's presentation
might have already seen
this, but this is just
sort of an overview of what the
physical web experience looks
like today on iOS and Android.
So on iOS, for anyone
who has an iPhone,
you know, feel free to
start playing with this now.
But the main sort of
surface for interaction
for the physical web is
through the Today view,
which is a concept that
iOS introduced, I believe,
a couple releases ago
that's effectively Apple's
interpretation of widgets.
And so Chrome has a Today view
widget that users can add.
And whenever you're
around a Beacon,
you can opt into the
physical web contextually.
And then in the
future, whenever you're
around Beacons that
are broadcasting URLs,
you'll be able to see
those lists of URLs
when you go to this
dedicated Today view.
On Android, the story is
a little bit different,
because we can have a little
bit more flexibility in the way
that we do notification
management.
And so the main sort of mode
of interaction on Android
is a low priority
notification, which
is a notification that's
delivered to the user's device
without buzzing or
vibrating the phone.
So it still appears sort of in
the standard notification tray.
When the user
swipes down, they'd
be able to see the low priority
notification on the bottom,
but without it interrupting
the users workflow.
So this is our way
of allowing users
to always go to a persistent UI
surface that has physical web
URL's available there if
they're around a Beacon
without interrupting their work.
So whenever you're
around a Beacon,
be able to swipe down, see
this notification, tap on it,
and see the list
of nearby websites.
And when you're not
around to Beacon,
the notification just
clears itself away.
NIRDHAR KHAZANIE: And I think
the awesome part about this
is, you don't even have
to have an app installed.
ANIRUDH MOHAN: Right.
NIRDHAR KHAZANIE: Like
it's directly there
with the experience and
you can deploy content.
ANIRUDH MOHAN: Yeah, right.
You just need Chrome, as a user.
HOI LAM: Cool.
Next can you talk a little
bit about the telemetry frame,
and you know how that helps
the developers on maintenance.
NIRDHAR KHAZANIE: Sure, yeah,
so I had actually mentioned
this a little bit earlier.
But with telemetry,
what we actually
do as Ani had also pointed
out about interleaving,
we actually say that you should
have a Eddystone UID as well
as TLM frame together.
And so interleaving those two
is kind of the recommendation
that we have.
Further, some of the
things that we can do today
within the platform in terms of
surfacing through the Proximity
Beacon API is if you
have a set of Beacons,
and then you want to know
what the actual health is
of that Beacon,
is it about to die
or what not, we can actually
provide an alert for that
and actually tell you yes
your Beacon is about to die,
you may want to go out and
actually change battery.
And then, in general, it's
kind of like we're really
focused on making sure
that those Beacons which
are positioned and when
you actually deployed,
them are exactly
where you get them.
So let's say that you have
deployed a set of Beacons,
and that someone came and
then just ripped it off
or something happened
where it's actually moved.
We can actually provide
an alert also saying
that a Beacon is moved as well.
So those are some of
the things that we
can do with telemetry today.
AUDIENCE: So is there reported
to just random people walking
by, or?
NIRDHAR KHAZANIE: Yeah so think
about it like this, right.
So if you have an app,
and so in your app,
if you have the nearby
API, then the nearby API
would then be able to
take TLM based packets
and then send that directly
to the Google Beacon platform.
And so through there,
we can basically
be able to determine and
then provide those alerts
accordingly to your apps.
HOI LAM: Question.
AUDIENCE: Yeah, what are the
conditions for using the Google
Beacon platform?
Is there like a
[INAUDIBLE] if you
go above a certain number of
Beacons, it's paid for, or?
HOI LAM: So the question there
is, what are the conditions,
and are there any charges using
the Google Beacon platform?
NIRDHAR KHAZANIE: So the Google
Beacon platform today is there.
So we have our developer
terms of service.
So when you actually sign up
for a Google Developer Console
account, you have to
basically go accordingly
to RTOS from there.
And then everything
is free for the public
to be able to go out and
use as long as you've
accepted the agreement.
And then you move
forward from there
with your actual deployments
and attachment data.
ANIRUDH MOHAN: And the same
is true for the physical web
as well.
There's no cost.
All you have to do is
point to Beacon to a URL.
HOI LAM: Cool.
Are there areas of
developer experience
that you guys want to improve?
NIRDHAR KHAZANIE: Yeah, I
would say the first thing is
provisioning an app.
And then being--
sorry, excuse me.
Provisioning a
Beacon directly so
that it works uniformly and
seamlessly within your app.
We're working really strongly
with all the different OEM's
on that.
And registration
is also something
that we're looking at,
trying to improve also
to make that a much more
seamless behind the scenes.
ANIRUDH MOHAN: For
larger developers
who might be deploying
a lot of Beacons,
we want to do a better
job of helping them
be able to do fleet management.
So remotely update
those Beacons,
manage the Beacons sort
of status and health.
Ninu mentioned the
telemetry frame.
We ran a lot of
experiments last year
with larger deployments that
leverage the telemetry frame.
So we hope to use some
of those learnings
this year in helping some of
our larger deployments out.
And finally, I'd say we want to
improve the scanning experience
on the nearby API's.
That's something
that we always think
we can do a better job of but
from a performance standpoint,
in terms of not using sort of
the user's device irresponsibly
to do scans and also from
a reliability standpoint,
making sure that we show nearby
Beacons as often as possible.
And that's something
that we're continually
investing in that we want
to improve this year.
HOI LAM: Actually question for
the audience, how many of you
have actually developed on
the Google Beacon platform?
Couple of you.
OK, are there any
things that you find
could be useful for
your own development?
Anything?
Nope.
NIRDHAR KHAZANIE: Oh
wow, you guys have--
ANIRUDH MOHAN: It's perfect.
[LAUGHTER]
NIRDHAR KHAZANIE: No
changes whatsoever.
Everything works great.
HOI LAM: You guys are fired.
ANIRUDH MOHAN: We're done.
NIRDHAR KHAZANIE: Yeah.
HOI LAM: You guys are done.
NIRDHAR KHAZANIE: We've
officially launched
successful products then.
ANIRUDH MOHAN:
Let's just go home.
NIRDHAR KHAZANIE:
Yeah, we're done.
No more road maps
HOI LAM: Excellent.
So, how much time do we have?
Five minutes, cool, are
there any live questions?
Ah one there, over there.
AUDIENCE: [INAUDIBLE]?
NIRDHAR KHAZANIE: Yeah, I'm
can share with you-- yeah sure.
You want to ask
the question again?
HOI LAM: The sort of question
there is whether we have a road
map of what is coming up next.
NIRDHAR KHAZANIE: Sure, what
I can share with you today
is we're very much still
focused on first party base
integrations.
So the products for
example like Google Now,
et cetera, we can't really
talk too much in that,
but I will tell you that
focusing all of our efforts
directly within our
first party products
is very important to us.
Where we're strategically
positioning the entire
Eddystone spec to make
sure that it works very
seamlessly behind the scenes.
And so being able to have
those integrations in place
are kind of what the entire
team are focusing on today.
So look for that in
the upcoming quarters,
and that's kind of what
I have to share today.
ANIRUDH MOHAN: On the
physical web side,
we're focused on two main things
over the next couple quarters.
One is strengthening our
cross-platform story,
so really investing in
our Android release.
That'll be coming
up this quarter.
And the second is continuing
to improve our ranking service.
Today in today's
world, there aren't
too many Beacons out there so
ranking isn't a huge problem
beyond making sure that we serve
high quality spam free results.
Over time, as we invest
in larger deployments,
we're expecting users to
discover lots of Beacons
out in the wild.
In which case, ranking
becomes increasingly
important to make sure that
we surface the most relevant,
the most useful results
first to the user.
So we want to continue
to invest there.
We talked about all this
stuff on our GitHub,
and we invite you guys to sort
of join the conversation if you
feel like there's
things you think
we should be improving
to, and we'll
do our best to respond quickly.
HOI LAM: There's one
question over there.
AUDIENCE: You guys sort
of answered my question
about the bandwidth
issue, but I was wondering
have you developed any
techniques on the installation
that you can recommend
or learn from
to avoid, say, interference
when you install it [INAUDIBLE].
Anything useful
like [INAUDIBLE]?
ANIRUDH MOHAN: I missed the
first part of your question,
but I'm--
HOI LAM: So is the
question of best practice
in terms of physical
deployments of Beacons?
AUDIENCE: Installing
them to avoid vandalism
but not affecting the signal.
HOI LAM: Yeah, so
the question there
is what are the best
practices in terms
of sticking the Beacons
up and preventing them
from being vandalized.
ANIRUDH MOHAN: Yeah we
find it hard typically
to provide generic
advice, because it's
so dependent on the room
and the physical location
that you're in, the
materials in the room,
the number of people that
tend to be in the room.
Because all these things
affect the interference
of the waves emitted
by the Beacons.
But general sort of trends that
we've observed, placing them
higher rather than
lower prevents vandalism
while also providing sort of
a more direct line of sight
to the user's device to decrease
the likelihood of path loss.
That tends to be something
that works better.
Other attributes
that are generic,
I'm trying to think of
off the top of my head.
HOI LAM: So you--
NIRDHAR KHAZANIE:
Try not to make sure
that there are any
obstructions which
are basically in the path
of the Beacon to the user.
That's probably the biggest one.
HOI LAM: Yeah, and also,
this is a tip from Scott,
he said, basically,
buy the strongest glue
that you can buy on the market.
You would not believe
how many Beacons just
fall off on their own.
And so that's one
top tip, there.
AUDIENCE: So duct tape
wouldn't be recommended.
No.
HOI LAM: Directly
from the source.
Scott say no.
ANIRUDH MOHAN: And
also when in doubt,
tend towards decreasing the
signal strength of the Beacon
rather than increasing, because
these things have a much
bigger range than you'd expect.
And in certain applications, you
wouldn't want a certain Beacon
to be discoverable from a
far away or adjacent room.
And so smaller signal
strength tends to help that.
AUDIENCE: What about glass?
Does glass affect
the signal much?
HOI LAM: So the
question there is
how does glass impact a signal?
What we find in the London
office is they pass straight
through, so increases
the range significantly.
Question?
AUDIENCE: At this point in time,
how many people are connected,
or interacting with a
particular [INAUDIBLE].
How do you get that [INAUDIBLE]?
HOI LAM: So the question
here is, how many people
are interacting with Beacons
through the Google Beacon
platform?
AUDIENCE: For
example, in this room
you've got [INAUDIBLE]
that's there for a number
to see how many people
are there, [INAUDIBLE]?
NIRDHAR KHAZANIE: Do you
want to restate that?
ANIRUDH MOHAN: Sure.
NIRDHAR KHAZANIE:
Sure, go ahead.
HOI LAM: So there's two
sides to that story.
I know that us
developers, we want
as much numbers and analytics
as we want or as we could
in terms of how many people
are seeing those Beacons.
So that the two sides
to that answer is, one
we want to protect
the users' privacy.
So in Scott's
presentation he said
that the developers
themselves would not
be able to see which
user can see their link
but not click on the
link in a physical web
to purely just protect privacy.
And it's a similar story
with application as well.
So when the application is
interacting with your app,
that you can write your
own analytics code and say,
oh this person opt in to use
the nearby functionality,
and they see these
three Beacons.
So you can collect those
kind of information, but only
with the user's permission.
AUDIENCE: So it's
more [INAUDIBLE].
HOI LAM: So the
follow up question
there is it's within
the app design
rather than within
the framework.
Yes, so it is within
your app that you
can collect the information
if the user give you
the permission.
NIRDHAR KHAZANIE: I think the
one thing I would really stress
is that, in Eddystone, we're
very focused on user privacy as
well as security.
So please keep that in mind
when you're building your apps.
Try to use the best practices
that we've set forth.
And I think that's something
that keep in mind as well,
to be able to establish that
user trust, keep it intact,
and not infringe upon
that on the user.
AUDIENCE: I was thinking
more from [INAUDIBLE].
HOI LAM: So the question
there, the follow up
question there is whether
there could be a background
service that could be
run in order to say which
part of store, which
part of the location
is most frequent by customers,
let's say, in that use case.
NIRDHAR KHAZANIE:
Yeah I think that's
a lot of those kind of
special kind of like needs
that you would want to have for
your app would be done directly
direct within your
app framework itself,
and whatever it is that you'd
be building a proprietary.
ANIRUDH MOHAN: So a
developer can still
ultimately log the
end user interaction
that's facilitated by a Beacon.
If they tap on a link,
if they take an action
that the Beacon sort of
supports, but not the
scan itself.
HOI LAM: Basically
you need to, I guess,
give some value back
to the user and explain
why you would need that.
Because the user it we need
to click on that permission
dialogue and say, yeah, I will
allow this app to track me.
So yeah, think about the perhaps
the user value side of things
as well.
ANIRUDH MOHAN: It's important to
keep in mind that the days are
still sort of early for
the Beacon ecosystem
and when we talk to
users about Beacon,
one of the foremost
concerns on their mind
is sort of privacy
and being logged.
And so we want to be especially
cognizant of making sure
that we're being
responsible about collecting
the minimum amount
of data possible,
if anything, in these
deployments while also
providing value.
HOI LAM: Maybe time for one
more question if there is one.
No, OK, you guys have done well.
Thank you very much.
NIRDHAR KHAZANIE: Thank you.
ANIRUDH MOHAN: Great, thank you.
[MUSIC PLAYING]
